Please refer to RP-213588 for detailed scope of the SI.
R1-2205574 Session notes for 9.5 (Study on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
R1-2205226 Work Plan for Study Item on Expanded and Improved NR Positioning Intel Corporation, CATT, Ericsson (rev of R1-2204805)
R1-2204804 Draft skeleton of TR38.859 Intel Corporation
[109-e-R18-Pos-01] – Debdeep (Intel)
Email discussion and approval of TR skeleton for Rel-18 SI on expanded and improved NR positioning by May 13
R1-2205353 Draft skeleton of TR38.859 Rapporteur (Intel Corporation)
R1-2205358 FL summary on TR 38.859 skeleton for Rel-18 SI on expanded and improved NR positioning Moderator (Intel Corporation)
Decision: As per email decision posted on May 16th,
Agreement
· TR skeleton in R1-2205398 for TR 38.859 for study on expanded and improved NR positioning is endorsed as v0.0.0.
R1-2205398 Draft skeleton of TR38.859 Rapporteur (Intel Corporation)
Including specific target performance requirements
R1-2205194 Potential SL Positioning Scenarios and Requirements Lenovo (rev of R1-2204557)
Proposal 1: RAN1 to select 1 or 2 representative commercial ranging use cases to derive commercial SL positioning requirements, preferably based on the KPIs, e.g., accuracy, latency aligned with that of V2X or Public Safety.
Proposal 2: Adopt a unified set of SL positioning requirements for all use cases as shown in Table 5 and for ease of evaluations, consider a common KPI target such as an absolute horizontal/vertical accuracy < 1m for 95% of UEs and a relative horizontal/vertical accuracy <1m for 95% of UEs.
Proposal 3: At least consider the following additional KPIs required SL Positioning use cases:
· Direction/orientation accuracy
· Concurrent UEs performing relative location estimation
· Mobility parameters including velocity. FFS whether absolute and/or relative velocity is required.
Decision: The document is noted.
R1-2204309 Discussion on SL positioning scenarios and requirements CMCC
Proposal 1: Select the following use cases for evaluation:
· First priority: V2X use cases
· Second priority: IIoT use cases
Proposal 2: Select set 2 defined in TR 38.845 as the target requirement for both V2X and IIoT use cases.
· Set 2: 1 – 3 m with 95 – 99 % confidence level.
Proposal 3: Study and evaluate the following coverage scenarios:
· First priority: in-coverage and out-of-coverage scenarios
· Second priority: partial coverage scenarios
Proposal 4: Support of sidelink positioning operation in ITS and licensed band in FR1.
Decision: The document is noted.
R1-2204948 SL positioning scenarios and requirements Ericsson
· Proposal 1: Study the mechanisms to support in-coverage hybrid positioning (Uu+PC5)
· Proposal 2: Public safety should be prioritized when selecting use cases and requirements for OoC
· Proposal 3: Evaluations of positioning performance in partial coverage scenarios should not be performed.
· Proposal 4: Target a small set of use cases for requirements and evaluations, that is, the ones presented in Table 1 and Table 2
Decision: The document is noted.
R1-2203057 Considerations on scenarios and target requirements for sidelink positioning FUTUREWEI
R1-2203127 SL positioning scenarios and requirements Nokia, Nokia Shanghai Bell
R1-2203162 Discussion on scenarios and requirements for sidelink positioning Huawei, HiSilicon
R1-2203334 Consideration on SL positioning scenarios and requirements Spreadtrum Communications
R1-2203465 Discussion on SL positioning scenarios and requirements CATT, GOHIGH
R1-2203564 Discussion on SL positioning scenarios and requirements vivo
R1-2203622 Discussion on scenarios and requirements for SL positioning ZTE
R1-2203718 Discussion on SL positioning scenarios and requirements LG Electronics
R1-2203737 Considerations on SL positioning scenarios and requirements Sony
R1-2203751 Scenarios and requirements for sidelink positioning MediaTek Inc.
R1-2203821 Discussion on sidelink positioning scenarios and requirement xiaomi
R1-2203909 On SL Positioning Scenarios and Requirements Samsung
R1-2203941 SL positioning scenarios and requirements NEC
R1-2203978 Discussion on SL positioning scenarios and requirements OPPO
R1-2204094 Discussion on V2X use cases, scenarios, and requirements for sidelink positioning TOYOTA Info Technology Center
R1-2204130 Potential scenarios and requirements for SL positioning InterDigital, Inc.
R1-2204251 Discussion on SL positioning scenarios and requirements Apple
R1-2204666 Views on SL positioning scenarios and requirements Sharp
R1-2204753 Discussion on sidelink based positioning requirements & scenarios CEWiT
R1-2204806 On SL positioning scenarios and requirements Intel Corporation
R1-2204833 SL positioning scenarios and requirements Fraunhofer IIS, Fraunhofer HHI
R1-2205036 Sidelink Positioning Scenarios and Requirements Qualcomm Incorporated
[109-e-R18-Pos-02] – Debdeep (Intel)
Email discussion on SL positioning scenarios and requirements by May 20
- Check points: May 16, May 20
Decision: As per email decision posted on May 16th,
Agreement
Following two operation scenarios are considered for studies on SL positioning:
· Scenario 1: PC5-only-based positioning
· Scenario 2: Combination of Uu- and PC5-based positioning solutions
R1-2205177 FL summary #1 on SL positioning scenarios and requirements Moderator (Intel)
From May 17th GTW session
Agreement
For evaluations for SL positioning:
· For V2X and public safety use-cases, at least in-coverage and out-of-coverage scenarios are considered.
· For IIoT and commercial use-cases, at least in-coverage scenarios are considered.
Agreement
For the purpose of evaluations, in-coverage and out-of-coverage scenarios are prioritized during the SI.
· Note: This prioritization is not intended to down-scope support of SL positioning for partial coverage scenarios.
Agreement
For evaluations for SL positioning:
· Operation in FR1 with channel bandwidths of up to 100 MHz are considered.
· Optional: Operation in FR2 with channel bandwidths of up to 400 MHz are considered.
Decision: As per email decision posted on May 19th,
Agreement
Positioning accuracy requirements for SL positioning are expressed as accuracy requirements of particular percentiles of UEs for one or more of the following metrics:
· Ranging accuracy, expressed as the difference (error) between the calculated distance/direction and the actual distance/direction in relation to another node
· Relative positioning accuracy, expressed as the difference (error) between the calculated horizontal/vertical position and the actual horizontal/vertical position relative to another node
· Absolute positioning accuracy. expressed the difference (error) between the calculated horizontal/vertical position and the actual horizontal/vertical position
· Note: the exact applicability of particular requirements may vary across use-cases
Agreement
For evaluations of relative positioning, the horizontal plane is assumed parallel to the ground.
R1-2205527 FL summary #2 on SL positioning scenarios and requirements Moderator (Intel)
From May 20th GTW session
Working assumption
For evaluation of V2X use-cases for SL positioning, the following accuracy requirements are considered:
· Set A (similar to “Set 2” defined in TR 38.845)
o Horizontal accuracy of 1.5 m (absolute and relative); Vertical accuracy of 3 m (absolute and relative) for 90% of UEs
· Set B (similar to “Set 3” defined in TR 38.845)
o Horizontal accuracy of 0.5 m (absolute and relative); Vertical accuracy of 2 m (absolute and relative) for 90% of UEs
· Note 1: For evaluated SL positioning methods, companies are expected to report:
o whether each of the two requirements are satisfied, and
o %-ile of UEs satisfying the target positioning accuracy for a requirement that may not be satisfied with 90%.
· Note 2: target positioning requirements may not necessarily be reached for all scenarios and deployments
· Note 3: all positioning techniques may not achieve all positioning requirements in all scenarios
Agreement
For evaluation of public safety use-cases for SL positioning solutions, the following accuracy requirements are considered:
· 1 m (absolute or relative) horizontal accuracy and 2 m (absolute or relative between 2 UEs) or 0.3 m (relative positioning change for one UE) vertical accuracy for 90% of UEs
· Relative speed: up to 30 km/hr.
· Note 1: For evaluated SL positioning methods, companies are expected to report:
o whether the requirement is satisfied, and
o %-ile of UEs satisfying the target positioning accuracy if the requirement may not be satisfied with 90%.
· Note 2: target positioning requirements may not necessarily be reached for all scenarios and deployments
· Note 3: all positioning techniques may not achieve all positioning requirements in all scenarios
Agreement
For evaluation of commercial use-cases for SL positioning solutions, the following accuracy requirements are considered:
· 1 m (absolute or relative) horizontal accuracy and 2 m (absolute or relative) vertical accuracy for 90% of UEs
· Relative speed: up to 30 km/hr.
· Note 1: For evaluated SL positioning methods, companies are expected to report:
o whether the requirement is satisfied, and
o %-ile of UEs satisfying the target positioning accuracy if the requirement may not be satisfied with 90%.
· Note 2: target positioning requirements may not necessarily be reached for all scenarios and deployments
· Note 3: all positioning techniques may not achieve all positioning requirements in all scenarios
Working assumption
For evaluation of IIoT use-cases for SL positioning solutions, the following accuracy requirements are considered:
· For horizontal accuracy,
o Set A: 1 m (absolute or relative) for 90% of UEs
o Set B: 0.2 m (absolute or relative) for 90% of UEs
· For vertical accuracy,
o Set A: 1 m (absolute or relative) for 90% of UEs
o Set B: 0.2 m (absolute or relative) for 90% of UEs
· Relative speed: up to 30 km/hr.
· Note 1: For evaluated SL positioning methods, companies are expected to report:
o whether each of the two requirements are satisfied, and
o %-ile of UEs satisfying the target positioning accuracy for a requirement that may not be satisfied with 90%.
· Note 2: target positioning requirements may not necessarily be reached for all scenarios and deployments
· Note 3: all positioning techniques may not achieve all positioning requirements in all scenarios
Decision: As per email decision posted on May 21st,
Agreement
For evaluations in Rel-18, ranging requirements for SL positioning are defined as:
· For a given use-case, the value of the distance requirement for ranging distance accuracy is same as the value identified for horizontal positioning accuracy for relative positioning.
· The requirement on ranging direction accuracy is Y degrees for 90% of UEs.
o FFS: Exact definition of ranging direction accuracy, including value(s) of Y and reference direction
Agreement
For Rel-18 studies on SL positioning, focus on positioning accuracy
· Note: End-to-end positioning latency is expected to satisfy a latency budget of X second(s).
o FFS: value of X
Final summary in R1-2205595.
Including evaluation methodology and performance evaluation results
R1-2204754 Discussion on evaluation methods and results of sidelink based positioning CEWiT
· Proposal 1: Rel 17 sidelink-based positioning evaluation should be performed for V2X, IIoT Public safety use cases for in coverage, partial coverage, and out of coverage scenarios.
· Proposal 2: For Rel 17 sidelink evaluation, the simulation parameters form 38.855 and 38.857 for public safety and IIoT use cases can be reused.
· Proposal 4: For uniform results, fix the UE dropping density per scenario that should be specified in the simulation assumptions.
Decision: The document is noted.
R1-2205186 Discussion on Evaluation for SL Positioning Samsung (rev of R1-2203910)
· Proposal 1: The following evaluation scenarios are defined for NR SL positioning studies
o Scenario 1. Out-of-coverage,
§ SL positioning should be able to work in stand-alone manner
§ Square model can be used and various inter-TP distance used for evaluation.
§ The movement from both reference UEs and measurement UE is considered in evaluation.
o Scenario 2. In-coverage,
§ SL positioning can be used to assist Uu positioning.
§ SL positioning can be used in stand-alone manner
§ UMi/Uma/Indoor models (TR38.885) and InF-SH/InF-DH models (TS38.857) can be reused.
o FFS: Specific parameters for the evaluation scenarios
· Proposal 2: At least CDFs of horizontal and vertical (vertical error not necessarily applicable to all solutions and/or scenarios) positioning errors are used as performance metrics in NR SL positioning evaluations
· Proposal 3: If RSU is considered for SL positioning evaluation, it can be treated as both UE type and gNB type.
· Proposal 4: Study for measurement UE to decide measurement source(s) for SL positioning with proper criteria.
Decision: The document is noted.
R1-2203128 Evaluation of SL positioning Nokia, Nokia Shanghai Bell
R1-2203163 Evaluation of SL positioning Huawei, HiSilicon
R1-2203466 Evaluation methodology and performance evaluation for SL positioning CATT, GOHIGH
R1-2203565 Evaluation of sideilnk positioning performance vivo
R1-2203623 Discussion on evaluation for SL positioning ZTE
R1-2203719 Discussion on evaluation of SL positioning LG Electronics
R1-2203822 Discussion on sidelink positioning evaluation methodology xiaomi
R1-2203942 Evaluation of SL positioning NEC
R1-2203979 Discussion on evaluation methodology of SL positioning OPPO
R1-2204061 Discussion on sidelink positioning design CENC
R1-2204131 Evaluation methodology for SL positioning InterDigital, Inc.
R1-2204252 On Evaluation of SL positioning Apple
R1-2204558 SL Positioning Evaluation Methodology Lenovo
R1-2204834 SL positioning evaluation methodology Fraunhofer IIS, Fraunhofer HHI
R1-2204949 Evaluation of SL positioning Ericsson
R1-2205037 Sidelink Positioning Evaluation Assumptions and Results Qualcomm Incorporated
[109-e-R18-Pos-03] – Chuangxin (ZTE)
Email discussion on evaluation of SL positioning by May 20
- Check points: May 16, May 20
Decision: As per email decision posted on May 17th,
Agreement
For SL positioning evaluation, V2X use case with highway and urban grid scenarios defined in TR 37.885 is supported.
· The road configuration for urban grid and highway provided in TR 37.885 Annex A is reused
Agreement
For SL positioning evaluation in highway and urban grid scenarios, UE dropping option A defined in section 6.1.2 of TR 37.885 is used, i.e.
· UE dropping option A is used for the highway scenario:
o Vehicle type distribution: 100% vehicle type 2.
o Clustered dropping is not used.
o Vehicle speed is 140 km/h in all the lanes as baseline and 70 km/h in all the lanes optionally.
· UE dropping option A is used for the urban grid scenario:
o Vehicle type distribution: 100% vehicle type 2.
o Clustered dropping is not used.
o Vehicle speed is 60 km/h in all the lanes.
o In the intersection, a UE goes straight, turns left, turns right with the probability of 0.5, 0.25, 0.25, respectively.
Agreement
For SL positioning evaluation in highway and urban grid scenarios, antenna model follows the description in TR 37.885 section 6.1.4.
· Vehicle UE option 1 is the baseline (Vehicle UE antenna is modelled in Table 6.1.4-8 and 6.1.4-9 in TR 37.885)
· Vehicle UE option 2 (two panels) can be optionally selected by companies
Agreement
For SL positioning evaluation in highway and urban grid scenarios, channel model follows description in TR 37.885 section 6.2.
R1-2205227 Summary #1 of [109-e-R18-Pos-03] Email discussion on evaluation of SL positioning Moderator (ZTE)
Agreement
· The following performance metrics for SL positioning accuracy evaluation is defined:
o For relative and absolute positioning
- horizontal accuracy
- vertical accuracy
o For ranging
- Ranging for distance, i.e. accuracy of distance
- Ranging for angle, i.e. accuracy of angle
· Companies are required to output
o The percentiles of positioning accuracy error including 50%, 67%, 80%, 90% of UEs,
- FFS others
o And the CDF of positioning accuracy error
· Performance metrics other than positioning accuracy, such as PHY/end-to-end latency, are up to companies
Agreement
· For absolute positioning evaluation, anchor UEs’ locations are known
o In the evaluation of SL only positioning
- Anchor UEs are used to locate target UEs
o In the evaluation of Joint Uu/SL positioning
- Both BS and anchor UEs are used to locate target UEs
· In the evaluation, relative positioning or ranging is performed between two UEs within X m
o FFS X which can be different for different scenarios, e.g. highway, urban grid, etc.
o Companies can consider to provide simulation results based on multiple X values
· Positioning method should be reported by companies.
Agreement
For SL positioning evaluation,
· The existing pattern and sequence of DL-PRS or positioning SRS can be reused as baseline for evaluation purpose.
o Companies should provide the description if other pattern and sequence are evaluated,
o AGC settling time is considered by companies
· Explicit simulation of all links, individual parameters estimation is applied. Companies should provide description of applied algorithms for estimation of signal location parameters.
· As baseline for absolute positioning, sidelink anchors location coordinates are perfectly known.
o Uncertainty in the sidelink anchors location coordinates can be considered by companies
· As baseline, Perfect synchronization between network and anchor UEs in the evaluation is assumed.
o Network synchronization error and timing errors defined in TR 38.857 Table 6-1 can also be optionally used by companies for Synchronization between BS and BS, between BS and anchor UEs, and between anchor UEs.
Agreement
For SL positioning evaluation in highway and urban grid, the following simulation parameters are used for FR1
Evaluation parameters for SL positioning in FR1
|
Parameters |
Urban grid for eV2X |
Highway for eV2X |
|
Carrier frequency |
Uu : 4 GHz SL: 6 GHz |
Uu : 2 GHz
or 4GHz |
|
BS Tx power |
Macro BS: 49dBm |
Macro BS: 49dBm |
|
UE Tx power |
Vehicle UE or UE type RSU: 23dBm |
Vehicle UE or UE type RSU: 23dBm |
|
BS receiver noise figure |
5dB |
5dB |
|
UE receiver noise figure |
9 dB |
|
R1-2205228 Summary #2 of [109-e-R18-Pos-03] Email discussion on evaluation of SL positioning Moderator (ZTE)
From May 17th GTW session
Agreement
· For SL absolute positioning evaluation in highway scenario, the following options are supported
o Alt 1 as optional: BS and UE-type RSU deployment follows TR 36.885, where wrap around method of 19*3 hexagonal cells with 500m ISD in Figure A.1.3-3 of TR 36.885 section A.1.3 is used.
o Alt 2 as baseline: BSs are disabled, UE-type RSUs are uniformly located with 200m spacing on both sides of highway symmetrically.
§ Optional: staggered/unsymmetrical UE-type RSU distribution like
·
· For SL absolute positioning evaluation in urban grid scenario, BS and UE-type RSU deployment follows the description in TR 36.885 section A.1.3.
o Companies can provide additional BS/ UE-type RSU deployment, e.g. additional UE-type RSUs are added to UE-type RSU deployment in TR 36.885
Note: For absolute positioning in highway, Alt 1 is assumed for evaluation of joint Uu/SL positioning, Alt 2 is assumed for evaluation of SL only positioning.
From May 20th GTW session
Agreement
· For evaluation of relative positioning or ranging in highway scenario
·
· For evaluation of relative positioning or ranging in urban grid scenario
Agreement
· For SL positioning evaluation, simulation bandwidths of 10, 20, 40 and 100 MHz in FR1 can be used.
· For SL positioning evaluation, simulation bandwidths of 100, 200 and 400MHz in FR2 can be used.
Agreement
· For SL positioning evaluation of Public safety use cases
· For SL positioning evaluation of Commercial use cases
Decision: As per email decision posted on May 21st,
Agreement
For SL positioning evaluation for IIOT use cases, InF-SH and/or InF-DH defined in TR 38.857 are used.
Agreement
For SL positioning evaluation on indoor factory scenarios, companies can select one of the following options for UE-2-UE channel model
· Option 1: BS-2-UE channel model defined in TR 38.901 is revised
o The UE parameters in the channel model defined in 38.901, e.g. UE height, antenna model, transmit power are used to replace gNB’s corresponding parameters.
§ Anchor UE height should be reported by companies, e.g. anchor UE height is the same as TRP.
· Option 2: D2D channel mode from 36.843 A.2.1.2 is used
Agreement
For SL positioning evaluation on IIOT use case, the performance metrics at least include absolute accuracy and relative accuracy.
· FFS how to select anchor UEs/RSU for absolute positioning, e.g. 20 anchor UEs/RSU are randomly deployed in the simulation area
R1-2203566 Discussion on potential solutions for sidelink positioning vivo
· Proposal 1: Prioritize RTT and AoA for sidelink positioning considering to achieve relative positioning and ranging (e.g., ranging for distance and ranging for angle).
· Proposal 2: Prioritize sidelink-based positioning. The combination of SL positioning with Uu positioning is of low priority.
· Proposal 3: Double-side RTT should be considered for SL positioning.
· Proposal 4: Two antenna panels as the distributed antenna system can be considered for V2X positioning.
· Proposal 5: Introduce a new SL reference signal (i.e., SL PRS) for SL positioning.
·
Proposal
6: The 
of SL PRS can be associated
with some UE information (e.g., pre-configured sequence ID, source ID).
· Proposal 7: AGC and GP symbol are needed for the SL PRS pattern.
· Proposal 8:
o Support reuse of one or more comb sizes of DL-PRS for the SL-PRS pattern.
o Partial staggered pattern can be considered for SL-PRS pattern considering SL structure (e.g, excluding the PSCCH symbol, AGC, or GP symbol for SL-PRS transmission).
· Proposal 9:
o SL PRS can be transmitted without PSSCH transmission in the resource pool.
o SCI should be transmitted with the associated SL PRS.
o Slot level SL PRS transmission should be supported.
· Proposal 10: A dedicated resource pool should be studied for SL PRS transmission in Rel-18.
· Proposal 11: SL mode 1 and mode 2 resource allocation mechanisms should be studied.
· Proposal 12: SL mode 2 resource allocation can be used for SL PRS resource allocation with some modification (e.g., the SL PRS is used for RSRP measurement).
· Proposal 13: The unified SL Positioning method can be introduced to support reporting one or more measurement results, similar to the TRP measurement result in TS 38.455.
· Proposal 14: Suggest UE Rx – Tx time difference for SL positioning can be defined as T, which is the timing gap between transmission of SL-PRS and receiving SL-PRS to/from other UE.
· Proposal 15: SL-PRS RSRP is needed to be introduced for SL-PRS measurement and reporting.
· Proposal 16: SL-AoA is needed to be introduced for SL-PRS measurement and reporting.
· Proposal 17: Unicast, groupcast and broadcast should be studied for SL positioning in Rel-18.
· Proposal 18: Open-loop power control scheme should be studied for SL PRS.
Decision: The document is noted.
R1-2204385 Discussions on potential solutions for SL positioning NTT DOCOMO, INC.
· Proposal 1: For SL-positioning, at least RTT mechanism is supported.
· Proposal 2: For SL-positioning, study whether TDOA mechanism can be supported or not, in consideration of time-misalignment among synchronizing UEs.
· Proposal 3: Support the following SL-positioning procedure to obtain its own location.
o Step 1: UE that requires its own location transmits information and/or signal to surrounding UEs
o Step 2: The surrounding UEs receive the information and/or signal and transmit corresponding information and/or signal to the UE
· Proposal 4: Study whether a case where a UE requires other UE’s location is considered in Rel-18 SL positioning or not.
· Proposal 5: Study whether SL-positioning can use Uu measurement or not.
o If supported, some UE in SL-positioning method can be replaced to gNB.
· Proposal 6: Study availability of Uu positioning instead of SL-positioning in use cases assumed for SL-positioning.
o If available, study priority order between Uu positioning and SL positioning and detailed procedure.
· Proposal 7: For SL-positioning,
o Study details on configuration/indication/report
o Study measurement UE determination
o Study cast-type to be used in SL-positioning method
· Proposal 8: Support SL-positioning RS multiplexed on PSSCH.
· Proposal 9: Study the following alternatives for SL-PRS.
o Alt 1: Define SL-PRS as a new reference signal.
§ Configuration/Indication/Cast-type/Mapping resource/Mapping procedure (rate-matching vs puncturing)/Sequence
o Alt 2: Define SL-PRS as an existing reference signal.
§ Configuration/Indication/Cast-type/Mapping resource modification
Decision: The document is noted.
R1-2203058 Considerations on sidelink reference signals for positioning purposes FUTUREWEI
R1-2203129 Potential solutions for SL positioning Nokia, Nokia Shanghai Bell
R1-2203164 Discussion on solutions to support SL positioning Huawei, HiSilicon
R1-2203335 Consideration on potential solutions for SL positioning Spreadtrum Communications
R1-2203467 Discussion on potential solutions for SL positioning CATT, GOHIGH
R1-2203624 Discussion on potential solutions for SL positioning ZTE
R1-2203659 Discussion on potential solutions for sidelink positioning China Telecom
R1-2203720 Discussion on potential solutions for SL positioning LG Electronics
R1-2203738 Considerations on potential solutions for SL positioning Sony
R1-2203752 The potential solutions for sidelink positioning MediaTek Inc.
R1-2203823 Discussion on sidelink positioning solutions xiaomi
R1-2203911 Discussion on Potential Solutions for SL Positioning Samsung
R1-2203943 Discussion on Potential Solutions for SL Positioning NEC
R1-2203980 Discussion on potential solutions for SL positioning OPPO
R1-2204092 carrier phase measurement method for sidelink positioning Locaila
R1-2204132 Potential solutions for SL positioning InterDigital, Inc.
R1-2204253 Discussions on Potential solutions for SL positioning Apple
R1-2204310 Discussion on potential solutions for SL positioning CMCC
R1-2204559 On Potential SL Positioning Solutions Lenovo
R1-2204667 Views on potential solutions for SL positioning Sharp
R1-2204755 Discussion on potential solutions for sidelink based positioning CEWiT
R1-2204835 Potential solutions for SL positioning Fraunhofer IIS, Fraunhofer HHI
R1-2204869 Views on potential solutions for SL positioning ROBERT BOSCH GmbH
R1-2204940 Views on potential solutions for SL positioning Intel Corporation
R1-2205151 Potential solutions for SL positioning Ericsson (rev of R1-2204950)
R1-2205038 Potential Solutions for Sidelink Positioning Qualcomm Incorporated
[109-e-R18-Pos-04] – Alex (Qualcomm)
Email discussion on potential solutions for SL positioning by May 20
- Check points: May 16, May 20
Decision: As per email decision posted on May 16th,
Agreement
Study power control mechanisms for SL-PRS transmission, including whether it is necessary.
R1-2205202 Moderator Summary #1 for [109-e-R18-Pos-04] Email discussion on potential solutions for SL positioning Moderator (Qualcomm)
From May 17th GTW session
Agreement
With regards to the Positioning methods supported using SL measurements study further the following methods:
· Note: When the study of carrier phase positioning and the evaluations of sidelink positioning have progressed, it can be reviewed whether carrier phase for sidelink can be considered in further work. Checkpoint at RAN1#110-e-Bis to see if sufficient information is available for this review.
· Note: Companies are encouraged to describe the role of SL nodes and their interaction/coordination participating in each method.
Decision: As per email decision posted on May 19th,
Agreement (Above agreement is revised from May 17th GTW session as shown in red)
Agreement
With regards to the numerologies of the SL-PRS, limit the study to those supported for NR Sidelink.
· Note 1: NR Sidelink supports {15, 30, 60 kHz} in FR1 and {60, 120 kHz} in FR2
· Note 2: This doesn’t imply that SL-PRS FR2-specific optimization(s) are expected to be studied
Agreement
Study new reference signal for SL positioning/ranging using the existing PRS/SRS design and SL design framework as a starting point.
· The study could at least include: Sequence design, frequency domain pattern, time domain pattern (e.g. number of symbols, repetitions, etc), time domain behavior, configuration/triggering/activation/de-activation of the SL-PRS, AGC time, Tx-Rx Turanround time, supportable bandwidth(s), multiplexing options with other SL channels, randomization/orthogonalization options.
· Note: The study of existing SL reference signal for SL positioning/ranging is not precluded. Companies are encouraged to perform performance evaluation/comparison to investigate whether such reference signals can meet the positioning accuracy requirements.
Agreement
With regards to the configuration/activation/deactivation/triggering of SL-PRS, study the following options:
Agreement
With regards to the Sidelink Positioning measurement report,
· Study the contents of the measurement report (e.g. time stamp(s), quality metric(s), ID(s), angular/timing/power measurements, etc)
· Study the time domain behavior of the measurement report (e.g. one-shot, triggered, aperiodic, semi-persistent, periodic)
· FFS whether the Sidelink Positioning measurement can be a high-layer report and/or a lower layer report.
Agreement
For the purpose of RAN1 discussion during this study item, at least the following terminology is used:
R1-2205457 Moderator Summary #2 for [109-e-R18-Pos-04] Email discussion on potential solutions for SL positioning Moderator (Qualcomm)
From May 20th GTW session
Agreement
For the purpose of RAN1 discussion during this study item, at least the following terminology is used:
· Anchor UE: UE supporting positioning of target UE, e.g., by transmitting and/or receiving reference signals for positioning, providing positioning-related information, etc., over the SL interface.
o FFS: clarification of the knowledge of the location of the anchor UE
Decision: As per email decision posted on May 21st,
With regards to the frequency domain pattern, study further a Comb-N SL-PRS design. Study at least the following aspects:
· N>=1 (where N=1 corresponds to full RE mapping pattern)
· Fully staggered SL-PRS pattern (e.g., M symbols of SL-PRS with comb-N with M=N and, at each symbol a different RE offset is used), Partially staggered SL-PRS pattern (e.g., M symbol(s) of SL-PRS with comb-N, with M<N, at each symbol a different RE offset is used), Unstaggered SL-PRS patterns (e.g., M symbol(s) of SL-PRS with comb- N, at each symbol a same RE offset is used, N > 1)
· The number of symbols of SL-PRS within a slot
o Any relation to the comb-N option
o RE offset pattern repetitions within a slot
· FFS: Other frequency domain pattern(s)
Agreement
For a potential new SL PRS, study further the following
· Number of symbol(s) for AGC and/or Rx-Tx turnaround time
· Conditions under which AGC training and/or Rx-Tx turnaround time are needed
Agreement
With regards to the SL Positioning resource allocation, study further the following 2 options for SL Positioning resource (pre-)configuration:
Agreement
With regards to the SL-PRS resource allocation, study the following two schemes:
· Scheme 1: Network-centric operation SL-PRS resource allocation (e.g. similar to a legacy Mode 1 solution)
o The network (e.g. gNB, LMF, gNB & LMF) allocates resources for SL-PRS
· Scheme 2: UE autonomous SL-PRS resource allocation (e.g. similar to legacy Mode 2 solution)
o At least one of the UE(s) participating in the sidelink positioning operation allocates resources for SL-PRS
o Applicable regardless of the network coverage
· FFS: potential mechanisms, if needed, for SL-PRS resource coordination across a number of transmitting UEs (e.g. IUC-like solutions).
· Note: Other Schemes are not precluded to be studied
· FFS how to handle resource allocation of SL-Positioning measurement report
R1-2203165 Error source for NR RAT-dependent positioning Huawei, HiSilicon
R1-2203177 Initial Views on solutions for integrity of RAT-dependent positioning techniques Nokia, Nokia Shanghai Bell
R1-2203336 Consideration on solutions for integrity of RAT dependent positioning techniques Spreadtrum Communications
R1-2203468 Discussion on solutions for integrity of RAT dependent positioning techniques CATT
R1-2203567 Discussion on solutions for integrity of RAT dependent positioning vivo
R1-2203625 Discussion on integrity of RAT dependent positioning ZTE
R1-2203739 Considerations on solution for integrity of RAT dependent positioning techniques Sony
R1-2203912 Discussion on Integrity of RAT Dependent Positioning Samsung
R1-2203965 Discussions on Integrity for NR Positioning OPPO
R1-2204133 Integrity for RAT dependent positioning techniques InterDigital, Inc.
R1-2204311 Discussion on solutions for integrity of RAT-dependent positioning techniques CMCC
R1-2204386 Discussion on solutions for integrity of RAT dependent positioning techniques NTT DOCOMO, INC.
R1-2204523 Discussion on integrity of RAT dependent positioning techniques LG Electronics
R1-2204560 Integrity for RAT-dependent positioning Lenovo
R1-2204668 Views on solutions for integrity of RAT dependent positioning techniques Sharp
R1-2204951 Solutions for integrity of RAT dependent positioning techniques Ericsson
R1-2205039 Integrity for RAT dependent positioning Qualcomm Incorporated
[109-e-R18-Pos-05] – Fumihiro (InterDigital)
Email discussion on integrity of RAT dependent positioning techniques by May 20
- Check points: May 16, May 20
Decision: As per email decision posted on May 17th,
Agreement
· Study sources of error for timing-based positioning and angle-based positioning methods, focusing on the following aspects
o Origin of the error source
§ e.g., At UE and/or network side
§ e.g., From assistance information, and/or measurements
o Model of the error source (e.g., distribution, mean and/or standard deviation for integrity overbounding model, range)
o Criteria to become an error source (e.g., whether it is quantifiable, how much influence an error source has on determination on integrity)
· It is encouraged to provide evaluation assumptions (e.g., requirements in TS 38.101, TS 38.104, TS 38.133, evaluation assumptions in TR 38.857) if evaluation is used to determine a distribution, mean and standard deviation or range of values of an error source
· UE-based/assisted DL positioning methods, UL and DL&UL positioning methods are considered in the study
Agreement
· At least the following error sources for timing-based positioning methods are studied
o TRP/UE measurements errors (e.g., ToA, Rx-Tx timing difference)
§ FFS: Effect of multipath/NLoS channels on TRP/UE measurement errors
o Error in assistance data (e.g., TRP location, Inter-TRP synchronization errors (e.g., RTD))
o TRP/UE Timing error
o FFS: Further study identification of error sources resulting from the multipath/NLoS channel/radio propagation environment, including multipath/NLoS channel itself as an error source
· Other error sources are not precluded
· FFS: details of each error source, e.g., mean/standard deviation/range associated with each error
Agreement
· At least the following error sources for angle -based positioning methods are studied
o TRP/UE measurements errors (e.g., AoA, RSRP, RSRPP expectedAoD/AoA)
§ FFS: Effect of multipath/NLoS channels on TRP/UE measurement errors
o Error in assistance data (e.g TRP location, TRP beam antenna information)
o FFS: Further study identification of error sources resulting from the multipath/NLoS channel/radio propagation environment, including multipath/NLoS channel itself as an error source
· Other error sources are not precluded
· FFS: details of each error source, e.g., mean/standard deviation/range associated with each error
Decision: As per email decision posted on May 18th,
Agreement
For the purpose of discussion of error sources, reuse the definitions for RAT-dependent integrity and update the references to GNSS in Section 8.1.1a in TS38.305 to also include RAT-dependent methods.
· Note: The intention of the proposal is not to make text proposals for TS 38.305
· FFS: whether to modify and/or how to modify, for the purpose of discussion in RAN1, terms in 8.1.1a in TS 38.305 (e.g., definitions for “Error”, “Bound”, “Time-to-Alert (TTA)”, “DNU”, “Residual Risk”, “irMinimum, irMaximum”) for RAT dependent positioning methods
Decision: As per email decision posted on May 21st,
In addition to the agreed aspects for the study, study the following aspects for error sources for timing/angle based positioning methods
· Mapping between an error source and a positioning method (e.g., DL, UL, DL&UL positioning method)
o e.g., error in TRP location can be an error source for UE-based DL-AoD
· Other aspects are not precluded
Final summary in R1-2205344.
R1-2203469 Discussion on improved accuracy based on NR carrier phase measurement CATT
· Proposal 1: R18 SI should focus on reuse of existing R16 PRS and SRS first for reference signal.
· Proposal 2: Candidate DL/UL measurements for NR CPP may include the carrier phase measurement (Phase Of Arrival, POA), differential carrier phase measurement (Phase Difference Of Arrival, PDOA) and measurement quality indication. The PDOA can be the POA difference between different gNB/TRPs or the POA difference between different antennas of same UE. The measurement quality indication can include one or combination of following items: LOS/NLOS indicator, Rician factor, SINR, and variance of CPP measurement, etc.
· Proposal 3: Joint reporting of POA and TOA for smoothing TOA with POA can be studied to improve the traditional DL/UL-TDOA performance.
· Proposal 4: At least the following two methods to eliminate the impact of ATA/AFA can be studied.
o Method 1: UE reports both the value and time stamp of ATA and/or AFA to the network side.
o Method 2: Network controls the effective time window of ATA and AFA for UE.
· Proposal 5: Both time-domain and frequency-domain methods for carrier phase measurement with non-continuous signal can be studied.
· Proposal 6: Both continuous location tracking algorithm and one-shot location calculation algorithm can be studied for solution for UE location calculation with integer ambiguity.
· Proposal 7: Carrier phases measurements from two or more carrier frequencies are helpful for fast resolution of the integer ambiguity.
· Proposal 8: Double differential technique with PRU can be used for solution for timing offset between TRPs.
· Proposal 9: Reuse simulation assumption of InF-SH channel scenario in FR1 in Rel-17 for the simulation of CPP, where the key simulation parameters in Table 1 can be considered..
Decision: The document is noted.
R1-2203634 Use cases and applications on Carrier Phase Based Positioning for NR Locaila
· Proposal 1: Study new reference signaling efficient for supporting phase-based measurement method
· Proposal 2: Investigate ambiguity resolution methods and necessary impact on the 5G NR system
· Proposal 3: Study phase based DL-AoD measurement method and necessary impact on 5G NR system
Decision: The document is noted.
R1-2203626 Discussion on Carrier Phase Measurement Based Positioning ZTE
· Proposal 1: InF-SH is used for evaluation of carrier phase based positioning.
· Proposal 2: The bandwidth (e.g., 100MHz) used for evaluation of carrier phase based positioning should be aligned among companies.
· Proposal 3: Consider to specify carrier phase measurement based positioning in Rel-18.
· Proposal 4: Discuss whether carrier phase measurement is an independent positioning method or is configured under each legacy positioning method.
· Proposal 5: Discuss whether LMF based or UE based solution or both is supported. Also discuss whether UL or DL carrier phase measurement or both is supported.
· Proposal 6: Discuss how the carrier phase estimation can be achieved based on the existing PRS or SRS, e.g. from frequency domain channel estimation or time domain channel estimation.
Decision: The document is noted.
R1-2203166 Discussion on NR carrier phase positioning Huawei, HiSilicon
R1-2203178 Initial Views on improved accuracy based on NR carrier phase measurement Nokia, Nokia Shanghai Bell
R1-2203337 Consideration on improved accuracy based on NR carrier phase measurement Spreadtrum Communications
R1-2203568 Discussion on carrier phase measurement enhancements vivo
R1-2203635 "Continuous PRS for improved carrier phase measurement Document for: Discussion & Decision" Dankook University
R1-2203660 Discussion on improved accuracy based on NR carrier phase measurement China Telecom
R1-2203753 On carrier phase measurement MediaTek Inc.
R1-2203824 Improved accuracy based on NR carrier phase measurement xiaomi
R1-2203913 Discussion on NR Carrier Phase Measurement Samsung
R1-2203966 Discussions on Carrier Phase Measurement for NR Positioning OPPO
R1-2204134 Potential solutions for carrier phase based positioning InterDigital, Inc.
R1-2204312 Discussion on carrier phase positioning CMCC
R1-2204387 Discussion on improved accuracy based on NR carrier phase measurement NTT DOCOMO, INC.
R1-2204524 Discussion on OFDM based carrier phase measurement in NR LG Electronics
R1-2204561 On NR carrier phase measurements Lenovo
R1-2204669 Views on improved accuracy based on NR carrier phase measurement Sharp
R1-2204807 Design Aspects of Carrier Phase Measurements for NR Positioning Enhancements Intel Corporation
R1-2204836 NR carrier phase measurements for positioning Fraunhofer IIS, Fraunhofer HHI
R1-2204952 Improved accuracy based on NR carrier phase measurement Ericsson
R1-2205040 Phase Measurements in NR Positioning Qualcomm Incorporated
[109-e-R18-Pos-06] – Ren (CATT)
Email discussion on improved accuracy based on NR carrier phase measurement by May 20
- Check points: May 16, May 20
Decision: As per email decision posted on May 16h,
Agreement
NR carrier phase positioning performance will be evaluated at least with the carrier phase measurements of a single measurement instance.
Decision: As per email decision posted on May 17th,
Agreement
The impact of integer ambiguity on NR carrier phase positioning and potential solutions to resolve the integer ambiguity will be studied in the SI.
Decision: As per email decision posted on May 19th,
Agreement
The study of the accuracy improvement based on NR carrier phase measurements in Rel-18 SI may include:
· UE-based and UE-assisted carrier phase positioning,
· UL carrier phase positioning and DL carrier phase positioning.
· NR carrier phase positioning with the carrier phase measurements of one carrier frequency or multiple frequencies
· Combination of NR carrier phase positioning with another standardized Rel. 17 positioning method, e.g., DL-TDOA, UL-TDOA, Multi-RTT, etc.
· Note: The use of “carrier phase positioning” does not necessarily mean it is a standalone positioning method
· FFS: whether SL carrier phase positioning is to be discussed in Rel-18 SI
Agreement
· The impact of multipath for the carrier phase positioning will be evaluated during the SI
· The methods of mitigating the impact of multipath for the carrier phase positioning will be studied during the SI, if it is considered to be necessary after the evaluation.
R1-2205164 FL Summary for improved accuracy based on NR carrier phase measurement Moderator (CATT)
From May 20th GTW session
Agreement
· Reuse the simulation assumptions of NR Rel-16/17 for carrier phase positioning
o Note: Optional modification of the simulation assumptions defined in NR Rel-16/17 are allowed only if needed.
· The evaluation scenarios:
o Baseline: InF-SH, InF-DH
o Optional: IOO, Umi, Highway
§ Note 1: Other evaluation scenarios are not precluded.
§ Note 2: Existing Rel-17 DL/UL reference signals in Uu interface is to be used for the Highway scenario.
· Frequency range:
o Baseline: FR1
o Optional: FR2
Agreement
· In addition to the evaluation assumptions of NR Rel-16/17, the following error sources may also be considered during the evaluation:
o Phase noise (FR2)
o CFO/Doppler
o Oscillator-drift
o Transmitter/receiver antenna reference point location errors
o Transmitter/receiver initial phase error
o Phase center offset
· Note: Other error sources are not precluded
· Note: UE mobility can be considered in the evaluations
· Note: one or more error sources can be evaluated jointly
· Note: companies should provide the error sources model with their evaluations
Agreement
· For the purposes of discussion, for NR downlink and/or uplink carrier phase positioning, the carrier phase (CP) at a RF frequency at a receiver is a phase that is a function of the signal propagation time from an Tx antenna reference point of a transmitter (e.g., a TRP or a UE) to a Rx antenna reference point of the receiver (e.g., a UE or a TRP).
o The propagation time can be expressed in a fractional part of a cycle of the RF frequency and a number of integer cycles, but the CP may be independent of the number of integer cycles.
Agreement
The use of PRUs to facilitate NR carrier phase positioning can be evaluated in the SI by RAN1.
Final summary in R1-2205165.
Including discussions on requirements, evaluations, and potential enhancements.
R1-2203167 Requirements and evaluation methodology for LPHAP Huawei, HiSilicon
R1-2203179 Initial Views on LPHAP Nokia, Nokia Shanghai Bell
R1-2203470 Discussion on Low Power High Accuracy Positioning CATT
R1-2203569 Discussion on Low Power High Accuracy Positioning vivo
R1-2203627 Discussion on low power high accuracy positioning(LPHAP) ZTE
R1-2203825 LPHAP (Low Power High Accuracy Positioning) xiaomi
R1-2203914 Discussion on LPHAP Samsung
R1-2203967 Discussion on Low Power High Accuracy Positioning OPPO
R1-2204155 Discussions on Low Power High Accuracy Positioning (LPHAP) techniques InterDigital, Inc.
R1-2204313 Discussion on low power high accuracy positioning CMCC
R1-2204426 Discussion on Low Power High Accuracy Positioning Quectel
R1-2204525 Discussion on LPHAP in idle/inactive state LG Electronics
R1-2204562 LPHAP considerations Lenovo
R1-2204670 Views on low power high accuracy positioning Sharp
R1-2204953 On the requirements, evaluations and potential enhancements for Low Power High Accuracy Positioning) Ericsson
R1-2205041 Requirements, Evaluations, Potential Enhancements for Low Power High Accuracy Positioning Qualcomm Incorporated
[109-e-R18-Pos-07] – Jingwen (CMCC)
Email discussion on LPHAP by May 20
- Check points: May 16, May 20
Decision: As per email decision posted on May 16h,
Agreement
Confirm that use case 6 defined in TS 22.104 is the single representative use case for the study of LPHAP.
Agreement
At least the relative power unit is adopted as the performance metric to evaluate the power consumption of the Rel-17 RRC_INACTIVE state positioning and potential enhancements.
Agreement
A reference device (e.g., a mobile phone) with reference traffic type, reference battery capability, and reference battery life is defined for the purpose of identification of the performance gap that achieved by the Rel-17 RRC_INACTIVE state positioning baseline and the target battery life of LPHAP use case 6.
Agreement
· Adopt the following parameters as the common evaluation parameters for the LPHAP evaluation:
o Frequency range: FR1 (baseline); FR2 (optional)
o SCS: 30kHz for FR1 (baseline); 120kHz for FR2 (optional)
o BW of the DL PRS and UL SRS pos: 100MHz;
o Single-sample measurement per position fix (baseline); 4-sample measurement per position fix (optional)
o UE mobility: up to 3km/h
· Note: It is up to each company to provide detailed power model and evaluation results on power consumption in FR2.
Agreement
In the LPHAP evaluation, the power consumption of 5GC data traffic is not modelled. Only the power consumption of the traffic type related to LPHAP positioning (e.g., obtaining/updating SRS configurations, DL PRS measurement reporting, etc.) is considered.
· Note: This does not preclude the power consumption of paging monitoring in the baseline evaluation, but rather assumes that no power consumption of 5GC data traffic is considered during a power cycle.
Agreement
· Adopt the following power consumption model common for the baseline evaluation of Rel-17 RRC_INACTIVE state positioning.
|
Power State |
Relative power |
|
PDCCH-only (PPDCCH) |
50Note |
|
PDCCH + PDSCH (PPDCCH+PDSCH) |
120 |
|
SSB proc. (PSSB) |
50 |
|
UL |
250 (0 dBm) 700 (23 dBm) |
|
(Optional) PRACH |
[210] |
|
(Optional) BWP switching |
[50] |
|
(Optional) Intra-frequency RRM measurement (Pintra) |
[60] (synchronous case, N=8, measurement only; Pintra, meas-only) [80] (combined search and measurement; Pintra, search+meas) |
|
(Optional) Inter-frequency RRM measurement (Pinter) |
[60] (measurement only per freq. layer; Pinter, meas-only) [150] (neighbor cell search power per freq. layer; Pinter, search-only) Micro sleep power assumed for switch in/out a freq. layer |
|
Note: Power scaling to 20MHz reception bandwidth follows the rule in Section 8.1.3 of TR 38.840, i.e., max{reference power * 0.4, 50}. |
|
Agreement
· Adopt the following power consumption model for UL SRS for positioning transmission.
|
Power State |
Relative power |
|
SRS |
210 (baseline); 700 (optional) |
Decision: As per email decision posted on May 19h,
Agreement
· In Rel-18 low power and high accuracy positioning, adopt the following requirement:
o Horizontal positioning accuracy < 1 m for 90% of UEs
o Positioning interval / duty cycle of 15-30 s
o UE battery life of 6 months – 1 year
· Note: Setting an exact value each from the set of positioning interval / duty cycle and UE battery life in the evaluation and identification of performance gap will be discussed separately when necessary.
Conclusion
· At least when the positioning accuracy is evaluated without jointly evaluating the associated power consumption, the target horizontal positioning accuracy requirement on LPHAP of <1m can be achieved by Rel-16/17 positioning techniques with a positioning bandwidth of at least 100MHz.
· The main aspect of RAN1 evaluation is on power consumption.
· Note: This does not preclude the case that the positioning accuracy can be revisited, if found necessary at later stage.
Agreement
in which
§ C1 is the battery capacity of the reference device;
§ T1 is the battery life of the reference device;
§ P1 is the relative power unit obtained based on the reference traffic type;
§ X is the percentage of the power consumed by the reference traffic type;
§ C2 is the battery capacity of the LPHAP device;
§ P2 is the evaluated relative power unit of the LPHAP device;
§ P2_req is the target relative power unit of the LPHAP device;
§ T2_req is the target battery life of the LPHAP device
o Examples of these parameters are provided as follows:
|
C1 |
T1 |
X |
reference traffic type |
C2 |
T2req |
|
[4500] mAh |
[10] hours |
[20] % |
[FTP (model 3)] |
[800] mAh |
[12] months |
Decision: As per email decision posted on May 21st,
Agreement
Adopt the following periodicity of DL PRS / UL SRS for positioning in the baseline evaluation of Rel-17 RRC_INACTIVE positioning:
· 1 DL PRS / UL SRS for positioning occasion per N I-DRX cycle(s);
o Candidate values of N to evaluate is 1 and 8 for I-DRX cycle of 1.28s;
§ Note: Individual company may consider either one or both in the evaluation.
o Candidate value of N to evaluate is 1 for I-DRX cycle of 10.24s.
Agreement
· The I-DRX configuration is included in the baseline evaluation of Rel-17 RRC_INACTVIE positioning.
o Note: This does not preclude the case where no I-DRX cycle nor paging is considered in the evaluation of potential solutions to maximize the battery life.
· Adopt the following I-DRX cycle to evaluate:
o 1.28s (baseline); 10.24s (optional).
Agreement
· Adopt the power consumption model, additional transition energy and total transition time of the three sleep types (deep sleep, light sleep, and micro sleep) in TR38.840 as the evaluation baseline:
· FFS: whether/how an additional new ultra-deep sleep mode can be considered in the evaluation of potential solutions to maximize the battery life, including the determination of the relative power, additional transition energy and total transition time, if necessary.
Agreement
· Adopt the following reference configuration and assumption for DL PRS to define the power consumption model for DL PRS measurement:
o 1 Number of PFL;
o 8 DL PRS resources per slot are measured;
o DL PRS instance of smaller than or equal to 1 slot duration;
· Adopt the following table as the power consumption model for DL PRS measurement (derived from Table 22 in TR38.840):
|
N: Number of TRPs for DL PRS measurement |
Synchronous case (baseline) |
Asynchronous case (optional) |
||
|
FR1 (baseline) |
FR2 (optional) |
FR1 |
FR2 |
|
|
N=4 (baseline) |
120 |
195 |
140 |
255 |
|
N=8 (optional) |
150 |
225 |
170 |
285 |
Agreement
· For DL positioning, at least the following power components and parameter values are considered for the baseline evaluation of Rel-17 RRC_INACTIVE positioning:
o For the UE-assisted DL positioning,
§ SSB proc. with 2 ms duration and the periodicity of I-DRX cycle;
§ Paging with 2 ms duration, the periodicity of I-DRX cycle, and group paging rate of 10%;
§ DL PRS measurement with 0.5 ms duration;
§ CG-SDT with 1ms duration and the periodicity of positioning interval;
§ RRCRelease after the CG-SDT can be optionally included with [1] ms duration;
§ (Optional) BWP switching with [1] ms duration;
§ (Optional) Intra-/inter-frequency RRM measurement in low SINR condition with [1] ms duration;
§ (Optional) RA-SDT (e.g., including CORSET0 + SIB1, PRACH, RAR, Msg 3/4/5) in case of CG-SDT is unavailable;
o For the UE-based DL positioning,
§ SSB proc. with 2 ms duration and the periodicity of I-DRX cycle;
§ Paging with 2 ms duration, the periodicity of I-DRX cycle, and group paging rate of 10%;
§ DL PRS measurement with 0.5 ms duration;
§ (Optional) BWP switching with [1] ms duration;
§ (Optional) Intra-/inter-frequency RRM measurement in low SINR condition with [1] ms duration;
· Note: The power component and parameter values for UE-assisted DL positioning is also applicable to the DL part of UE-assisted DL+UL positioning method.
· Note: Individual company may consider additional power components and different parameter values in bracket in the evaluation.
· Note: Companies are encouraged to provide the assumption on the timeline between different power consumption events in the evaluation of potential enhancements to reduce the transition times between different power states and to extend the sleeping time as much as possible.
Agreement
· For UL positioning, at least the following power components and parameter values are considered for the baseline evaluation of Rel-17 RRC_INACTIVE positioning:
o SSB proc. with 2 ms duration and the periodicity of I-DRX cycle;
o Paging with 2 ms duration, the periodicity of I-DRX cycle, and group paging rate of 10%;
o UL SRS for positioning transmission with 0.5 ms duration;
o (Optional) BWP switching with [1] ms duration;
o (Optional) Intra-/inter-frequency RRM measurement in low SINR condition with [1] ms duration;
· Note: The power component and parameter values for UL positioning is also applicable to the UL part of UE-assisted DL+UL positioning method.
· Note: Individual company may consider additional power components and different parameter values in bracket in the evaluation.
· Note: Companies are encouraged to provide the assumption on the timeline between different power consumption events in the evaluation of potential enhancements to reduce the transition times between different power states and to extend the sleeping time as much as possible.
Final summary in R1-2205594.
Including performance evaluation of existing positioning procedures and measurements with RedCap UEs. The result of the evaluation will be used to assess the necessity of enhancements and, if needed, identify enhancements.
R1-2203168 Discussion on RedCap positioning Huawei, HiSilicon
· Proposal 1: Set the following target requirements for RedCap positioning:
o Horizontal positioning accuracy: <1m
o Vertical positioning accuracy: <3m
· Proposal 2: Identify positioning solutions suitable for RedCap UEs to achieve high accuracy positioning, i.e., sub-meter positioning accuracy.
Decision: The document is noted.
R1-2203968 Discussion on Positioning for RedCap UEs OPPO
· Proposal 1: Regarding the positioning support for RedCap UEs, support the following two categories of use cases:
o Commercial use cases mainly for wearables
o IIoT use cases mainly for industrial wireless sensors
· Proposal 2: To evaluate positioning performance of RedCap UEs, support the following scenarios and evaluation assumptions:
o For commercial use cases, select one or two of the following cases defined in Section 6.1 of TR 38.855
§ Case 1: Indoor Office
§ Case 2: UMi street canyon
o For IIoT use cases, select one or two of the following cases defined in Section 6 of TR 38.857
§ Case 3: InF-SH
§ Case 4: InF-DH
o FR1 is the first priority
o For the detailed information of evaluation assumptions for each case, refer to TR 38.855 and TR 38.857.
· Proposal 3: The support of positioning for RedCap UEs and any potential enhancement should not have large impact on the cost of RedCap UEs.
· Proposal 4: The requirements of positioning performance for RedCap UE should be lower than that of normal UEs.
o FFS: the exact values of requirements
Decision: The document is noted.
R1-2205042 Positioning for Reduced Capabilities UEs Qualcomm Incorporated
· Proposal 1: Send LS to RAN4 to ask them to include positioning requirements derived using simulation assumptions wherein 1 Rx is assumed at the UE.
· Proposal 2: For TDD scenarios,
o We propose to reuse NR Rel-16/17 Evaluation assumptions for InH, and UMI FR1 scenarios as agreed in RAN1 #94-Bis for 4 GHz and 2 GHz.
§ Support adding optionally to evaluate the UMI FR1 cases with DeltaTau modeling similar to the one introduced for InF scenarios.
o For FR1 FDD scenario introduce a new Urban Macro at 700 MHz with 500m ISD according to the simulation assumptions shown below.
o For FR2 TDD Redcap, reuse the NR Rel-16/17 FR2 simulation assumptions with 100 MHz PRS bandwidth.
· Proposal 3: Support Enhancements for Redcap devices, in both FR1 and FR2, to enable reaching a horizontal accuracy performance close to the NR Rel-17 positioning requirements at least in a subset of evaluation scenarios.
· Proposal 4: Study inter & intra-slot repetition of a DL PRS resource for the purpose of enabling receive PRS hopping for both FR1 and FR2.
· Proposal 5: Study inter & intra-slot repetition of a SRS resource for positioning for the purpose of enabling transmit SRS hopping for both FR1 and FR2.
· Proposal 6: Study PRS/SRS overlapping configuration for the purpose of enabling phase estimation across PRS hops both FR1 and FR2.
· Proposal 7: Study DL-PRS/ SRS resource configuration for the purpose of enabling transmitter PRS hopping.
· Proposal 8: For the purpose of Redcap positioning enhancements, study supporting Phase-Difference AoD.
· Proposal 9: For the purpose of Redcap positioning enhancements, study supporting Positioning measurements (RSTD, UE Rx-Tx, RSRPP) derived on SSB, TRS.
· Proposal 10: For the purpose of Redcap positioning enhancements, study supporting M-RTT using SRS-MIMO.
Decision: The document is noted.
R1-2203180 Initial Views on Positioning for RedCap UEs Nokia, Nokia Shanghai Bell
R1-2203471 Discussion on positioning for RedCap UEs CATT
R1-2203570 Discussion on positioning for RedCap UEs vivo
R1-2203628 Discussion on Positioning for RedCap UE ZTE
R1-2203696 Discussion on positioning support for RedCap UEs NEC
R1-2203740 Discussion on positioning for RedCap UEs Sony
R1-2203754 The potential solutions for RedCap UEs for positioning MediaTek Inc.
R1-2203826 Initial views on the positioning for RedCap UEs xiaomi
R1-2203915 Discussion on Positioning for RedCap Ues Samsung
R1-2204157 Evaluation assumptions and potential solutions for positioning for RedCap UEs InterDigital, Inc.
R1-2204254 Discussions on Positioning for RedCap UEs Apple
R1-2204314 Discussion on RedCap positioning CMCC
R1-2204388 Discussion on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2204425 Discussion on Positioning for RedCap UEs Quectel
R1-2204526 Discussion on positioning support for RedCap UEs LG Electronics
R1-2204563 Positioning for RedCap devices Lenovo
R1-2204671 Views on positioning for RedCap UEs Sharp
R1-2204808 On enhancements for NR positioning support of RedCap UEs Intel Corporation
R1-2204954 Positioning for RedCap UEs Ericsson
[109-e-R18-Pos-08] – Florent (Ericsson)
Email discussion on positioning for RedCap UEs by May 20
- Check points: May 16, May 20
Decision: As per email decision posted on May 15h,
Agreement
For evaluation of RedCap UE positioning performances, all RAT based positioning methods can be considered. Sources should detail the chosen method(s) when presenting performance evaluations.
Decision: As per email decision posted on May 19h,
Agreement
For evaluation of positioning performance of redcap UEs, adopt the general parameters are detailed in the table below
· TBD parameters are discussed separately
Table 6-1: Common scenario parameters applicable for all scenarios for Redcap UEs evaluations
|
|
FR1 Specific Values |
FR2 Specific Values |
|
Carrier frequency, GHz |
3.5GHz, 700MHz (optional) Note 1 |
28GHz Note 1 |
|
Bandwidth, MHz |
TBD |
TBD |
|
Subcarrier spacing, kHz |
30KHz, 15KHz (for 700MHz carriers) |
120kHz |
|
gNB model parameters |
|
|
|
gNB noise figure, dB |
5dB |
7dB |
|
UE model parameters |
|
|
|
UE noise figure, dB |
9dB – Note 1 |
13dB – Note 1 |
|
UE max. TX power, dBm |
23dBm – Note 1 |
23dBm – Note 1 EIRP should not exceed 43 dBm. |
|
UE antenna radiation pattern |
Omni, 0dBi |
Antenna model according to Table 6.1.1-2 in TR 38.855 |
|
PHY/link level abstraction |
Explicit simulation of all links, individual parameters estimation is applied. Companies to provide description of applied algorithms for estimation of signal location parameters. |
|
|
Network synchronization |
The network synchronization error, per UE dropping, is defined as a truncated Gaussian distribution of (T1 ns) rms values between an eNB and a timing reference source which is assumed to have perfect timing, subject to a largest timing difference of T2 ns, where T2 = 2*T1 – That is, the range of timing errors is [-T2, T2] – T1: 0ns (perfectly synchronized), 50ns (Optional) |
|
|
UE/gNB RX and TX timing error |
(Optional) The UE/gNB RX and TX timing error, in FR1/FR2, can be modeled as a truncated Gaussian distribution with zero mean and standard deviation of T1 ns, with truncation of the distribution to the [-T2, T2] range, and with T2=2*T1: - T1: X ns for gNB and Y ns for UE - X and Y are up to sources - Note: RX and TX timing errors are generated per panel independently
Apply the timing errors as follows: - For each UE drop, - For each panel (in case of multiple panels) - Draw a random sample for the Tx error according to [-2*Y,2*Y] and another random sample for the Rx error according to the same [-2*Y,2*Y] distribution. - For each gNB - For each panel (in case of multiple panels) - Draw a random sample for the Tx error according to [-2*X,2*X] and another random sample for the Rx error according to the same [-2*X,2*X] distribution. - Any additional Time varying aspects of the timing errors, if simulated, can be left up to each company to report. - For UE evaluation assumptions in FR2, it is assumed that the UE can receive or transmit at most from one panel at a time with a panel activation delay of 0ms. |
|
|
Note 1: According to TR 38.802 Note 2: According to TR 38.901 |
||
Agreement
For the evaluation of RedCap positioning, the following bandwidth can be evaluated:
· FR1: 20MHz baseline, 5MHz optional
· FR2: 100MHz
Agreement (further updated on May 21st as shown in red)
· Adopt the following table for the UE model parameters
|
|
FR1 Specific Values |
FR2 Specific Values |
|
UE model parameters |
|
|
|
UE antenna configuration |
Panel model 1 – Note 1
for 2Rx UEs: (M, N, P, Mg, Ng) = (1, 1, 2, 1, 1) |
• (M, N, P, Mg, Ng) = (1, 2, 2, 1, 1) as minimum antenna configuration (baseline) • (M, N, P, Mg, Ng) = (2, 2, 2, 1, 1) as optional configuration. |
|
UE antenna radiation pattern |
Omni, 0dBi |
Antenna model according to Table 6.1.1-2 in TR 38.855 |
|
Number of UE branches |
Baseline: 1Rx 1Tx Optional: 2Rx 1 Tx |
TBD |
|
Note 1: According to 3GPP TR 38.802 |
||
R1-2205526 Feature Lead Summary#1 for [109-e-R18-Pos-08] Positioning for RedCap Ues Moderator (Ericsson)
From May 20th GTW session
Agreement
The following scenarios are evaluated for positioning performance of Redcap
· Baseline: (Case 1): Umi street canyon, as described in Table 6.1-1-4 of 38.855
· Optional outdoor:
o (Case 2): Uma, as described in Table 6.1-1-6 of 38.855
o (Case 3): Rma (FFS details of the scenario)
· Baseline: (Case 4): InF-SH as described in Table 6.1-1 of 38.857
· Optional indoor: (Case 5) Indoor Open Office, as described in Table 6.1-1-3 of 38.855
· Optional indoor: (Case 6) InF-DH as described in Table 6.1-1 of 38.857
Agreement
The FR2 UE antenna configuration is as follow:
· (M, N, P, Mg, Ng) = (1, 2, 2, 1, 1) as minimum antenna configuration (baseline)
· (M, N, P, Mg, Ng) = (2, 2, 2, 1, 1) as optional configuration.
Agreement
The evaluation methodology for RedCap UEs positioning performance uses DL PRS and/or UL SRS for positioning.
· The methodology does not define any baseline reference signal configuration. Sources should detail the chosen configuration of reference signal(s) when presenting performance evaluations.
Agreement
For evaluation of positioning performance of redcap UEs in 700MHz band, the gNB antenna model is:
· gNB antenna configuration from TR38.830, (M,N,P,Mg,Ng) = (4,2,2,1,1), (dH, dV) = (0.5, 0.8)λ
Decision: As per email decision posted on May 21st,
Use 2Rx and 1Tx for baseline number of UE branches in FR2 in the UE antenna configuration table for RedCap UEs evaluation.
· FFS: optional configurations for number of UE branches in FR2.
Final summary in R1-2205636.
R1-2203181 Initial Views on Other topics for Positioning Nokia, Nokia Shanghai Bell
R1-2203472 Discussion on solutions of carrier phase positioning in multipath scenarios CATT
R1-2203571 Discussion on PRS measurement in IDLE state vivo
R1-2203629 Discussion on Positioning with Multiple Frequency Layers (Carriers) ZTE
R1-2203916 Discussion on expended and improved NR positioning Samsung
R1-2204158 Efficient usage of available bandwidths for positioning InterDigital, Inc.
R1-2204916 Considerations on the support of PRS/SRS bandwidth aggregation Huawei, HiSilicon, China Unicom
R1-2204955 Considerations for PRS/SRS bandwidth aggregation Ericsson
Please refer to RP-221814 for detailed scope of the SI.
R1-2208147 Session notes for 9.5 (Study on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
[110-R18-Pos] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Debdeeep (Intel)
R1-2207458 Draft TR 38.859 v001: Study on expanded and improved NR positioning Intel Corporation, CATT, Ericsson
R1-2208157 Draft TR 38.859 v010: Study on expanded and improved NR positioning Intel Corporation, CATT, Ericsson
R1-2208267 Draft TR 38.859 v010: Study on expanded and improved NR positioning Intel Corporation, CATT, Ericsson
Agreement
The draft TR in R1-2208267 is agreed in principle. TR38. 859 is endorsed as v0.1.0 in R1-2208275.
Including specific target performance requirements
R1-2205836 SL positioning scenarios and requirements Nokia, Nokia Shanghai Bell
R1-2205853 Discussion on SL positioning scenarios and requirements LG Electronics
R1-2205866 Remaining issues of scenarios and requirements for sidelink positioning Huawei, HiSilicon
R1-2205899 Discussion on scenarios and requirements for SL positioning ZTE
R1-2206044 Discussion on SL positioning scenarios and requirements vivo
R1-2206066 Discussion on requirements for sidelink positioning TOYOTA Info Technology Center
R1-2206122 Considerations on SL positioning scenarios Sony
R1-2206238 SL positioning scenarios and requirements NEC
R1-2206287 Discussion on SL positioning scenarios and requirements OPPO
R1-2206403 Discussion on SL positioning scenarios and requirements CATT, GOHIGH
R1-2206496 Potential SL Positioning Scenarios and Requirements Lenovo
R1-2206588 On scenarios and requirements for SL positioning Intel Corporation
R1-2206829 On SL Positioning Scenarios and Requirements Samsung
R1-2206916 Remaining issues on SL positioning scenarios and requirements CMCC
R1-2207071 Further discussion on sidelink based positioning requirements & scenarios CEWiT
R1-2207085 Discussions on SL positioning scenario and requirements InterDigital, Inc.
R1-2207236 Sidelink Positioning Scenarios and Requirements Qualcomm Incorporated
R1-2207282 Views on SL positioning scenarios and requirements Sharp
R1-2207340 Discussion on Sidelink positioning scenarios and requirements Apple
R1-2207507 Views on SL positioning scenarios and requirements ROBERT BOSCH GmbH
R1-2207577 Discussion on sidelink positioning scenarios and requirement Xiaomi
R1-2207618 Scenarios and requirements for sidelink positioning Ericsson
R1-2207626 Considerations on sidelink positioning in NR ITL
R1-2207738 FL summary #1 on SL positioning scenarios and requirements Moderator (Intel)
From Monday session
Agreement
· For ranging between two devices, ranging direction accuracy is defined as accuracy of angle of arrival (AoA) at a receiving node.
· The following requirements on ranging direction accuracy are considered:
o Set A: Y = ±15° for 90% of the UEs
o Set B: Y = ±8° for 90% of the UEs
o Note 1: For evaluations of ranging direction accuracy, companies are expected to report:
§ whether each of the two requirements are satisfied, and
§ %-ile of UEs satisfying the target positioning accuracy for a requirement that may not be satisfied with 90%.
o Note 2: target positioning requirements may not necessarily be reached for all scenarios and deployments.
o Note 3: all positioning techniques may not achieve all positioning requirements in all scenarios.
Agreement
· Confirm the following working assumption on positioning accuracy requirements for V2X with the changes indicated below:
o For evaluation of V2X use-cases for SL positioning, the following accuracy requirements are considered:
§ Set A (similar to “Set 2” defined in TR 38.845)
·
Horizontal accuracy of 1.5
m (absolute and or relative); Vertical accuracy of 3 m (absolute and or
relative) for 90% of UEs
§ Set B (similar to “Set 3” defined in TR 38.845)
·
Horizontal accuracy of 0.5
m (absolute and or
relative); Vertical accuracy of 2 m (absolute and
or relative) for 90% of UEs
§ Note 1: For evaluated SL positioning methods, companies are expected to report:
· whether each of the two requirements are satisfied, and
· %-ile of UEs satisfying the target positioning accuracy for a requirement that may not be satisfied with 90%.
§ Note 2: target positioning requirements may not necessarily be reached for all scenarios and deployments
§ Note 3: all positioning techniques may not achieve all positioning requirements in all scenarios
Agreement
· Confirm the following working assumption on positioning accuracy requirements for IIoT:
o For evaluation of IIoT use-cases for SL positioning solutions, the following accuracy requirements are considered:
§ For horizontal accuracy,
· Set A: 1 m (absolute or relative) for 90% of UEs
· Set B: 0.2 m (absolute or relative) for 90% of UEs
§ For vertical accuracy,
· Set A: 1 m (absolute or relative) for 90% of UEs
· Set B: 0.2 m (absolute or relative) for 90% of UEs
o Relative speed: up to 30 km/hr.
o Note 1: For evaluated SL positioning methods, companies are expected to report:
§ whether each of the two requirements are satisfied, and
§ %-ile of UEs satisfying the target positioning accuracy for a requirement that may not be satisfied with 90%.
o Note 2: target positioning requirements may not necessarily be reached for all scenarios and deployments
o Note 3: all positioning techniques may not achieve all positioning requirements in all scenarios
Conclusion
Further prioritization amongst the identified use-cases for SL positioning is not pursued during this SI in RAN1.
Final summary in R1-2208158.
Including evaluation methodology and performance evaluation results
R1-2205837 Evaluation of SL positioning Nokia, Nokia Shanghai Bell
R1-2205854 Discussion on evaluation of SL positioning LG Electronics
R1-2205867 Evaluation assumptions and results for SL positioning Huawei, HiSilicon
R1-2205900 Discussion on evaluation of SL positioning ZTE
R1-2206045 Evaluation of sidelink positioning performance vivo
R1-2206123 Initial Performance Evaluation of SL Positioning Sony
R1-2206239 Evaluation of SL positioning NEC
R1-2206288 Remaining details on evaluation methodology of SL positioning OPPO
R1-2206404 Evaluation methodology and performance evaluation for SL positioning CATT, GOHIGH
R1-2206830 Discussion on Evaluation for SL Positioning Samsung
R1-2207072 Discussion on evaluation methods and results of sidelink based positioning CEWiT
R1-2207086 Evaluation results for SL positioning InterDigital, Inc.
R1-2207124 Evaluation methodology for SL positioning Fraunhofer IIS, Fraunhofer HHI
R1-2207237 Sidelink Positioning Evaluation Assumptions and Results Qualcomm Incorporated
R1-2207508 Views on Evaluation of SL positioning for VRU Protection ROBERT BOSCH GmbH
R1-2207578 Discussion on evaluation of sidelink positioning Xiaomi
R1-2207605 FL summary#1 for SL positioning evaluation ZTE
R1-2207606 FL summary#2 for SL positioning evaluation ZTE
R1-2207619 Simulation assumptions and evaluations for NR SL positioning Ericsson
R1-2207686 SL Positioning Evaluation Methodology and Performance Lenovo (rev of R1-2206497)
R1-2207605 FL summary#1 for SL positioning evaluation ZTE
From Monday session
Agreement
For SL positioning evaluation in IIOT use case, companies should report how to drop anchor UEs and how to select anchor UEs
R1-2207606 FL summary#2 for SL positioning evaluation ZTE
From Wed session
Agreement
Adopt the tables in section 3 of R1-2207606 as templates to collect SL positioning simulation results from each company.
Agreement
For SL positioning evaluation purpose, the following assumptions are further adopted
· Companies should report whether SL-PRS and other SL signals are FDMed or not FDMed, and whether other SL signals are present
· Adopting system level simulations (rather than the link level simulations) as the baseline tool
· For SL positioning evaluation in highway scenario or urban grid scenario, the performance metrics can include absolute horizontal accuracy, relative horizontal accuracy, ranging with distance accuracy, and ranging with direction accuracy (optionally).
· In highway and urban grid scenarios, companies can further consider other UE types, e.g. pedestrian UE or VRU devices.
Agreement
In the evaluation, relative positioning or ranging is performed between two UEs within X m, where X value(s) are reported by companies, and companies should also report the minimum distance used in the evaluations for each use case. The assumption used for X will be included in the TR for each set of results.
R1-2205746 Potential sidelink positioning solutions FUTUREWEI
R1-2205838 Potential solutions for SL positioning Nokia, Nokia Shanghai Bell
R1-2205855 Discussion on potential solutions for SL positioning LG Electronics
R1-2205868 Discussion on solutions to support SL positioning Huawei, HiSilicon
R1-2205901 Discussion on potential solutions for SL positioning ZTE
R1-2205994 Discussion on potential solutions for SL positioning Spreadtrum Communications
R1-2206046 Discussion on potential solutions for sidelink positioning vivo
R1-2206124 Discussion on potential solutions for SL positioning Sony
R1-2206240 Discussion on Potential Solutions for SL Positioning NEC
R1-2206289 Discussion on potential solutions for SL positioning OPPO
R1-2206405 Discussion on potential solutions for SL positioning CATT, GOHIGH
R1-2206498 On Potential SL Positioning Solutions Lenovo
R1-2206589 Potential solutions for SL positioning Intel Corporation
R1-2206693 Discussion on potential solutions for sidelink positioning China Telecom
R1-2206831 Discussion on Potential Solutions for SL Positioning Samsung
R1-2206917 Discussion on potential solutions for SL positioning CMCC
R1-2207073 Discussion on enhancement for sidelink positioning support CEWiT
R1-2207087 Potential solutions for SL positioning InterDigital, Inc.
R1-2207125 Potential solutions for SL positioning Fraunhofer IIS, Fraunhofer HHI
R1-2207238 Potential Solutions for Sidelink Positioning Qualcomm Incorporated
R1-2207283 Views on potential solutions for SL positioning Sharp
R1-2207341 Discussions on Potential solutions for SL positioning Apple
R1-2207411 Discussion on potential solutions for SL positioning NTT DOCOMO, INC.
R1-2207443 Discussion on handling Anchor UE DENSO AUTOMOTIVE
R1-2207479 The potential solutions for sidelink positioning MediaTek Inc.
R1-2207484 Discussion on sidelink positioning ASUSTeK
R1-2207579 Discussion on sidelink positioning solutions Xiaomi
R1-2207620 On potential solutions for SL positioning Ericsson
R1-2207846 Moderator Summary #1 on potential solutions for SL positioning Moderator (Qualcomm)
R1-2207875 Moderator Summary #2 on potential solutions for SL positioning Moderator (Qualcomm)
From Wed session
Agreement
With regards to the Positioning methods supported using at least SL measurements, potential candidate positioning methods include at least the following:
Agreement
A new reference signal should be introduced for supporting SL positioning/ranging.
Agreement
Regarding SL-PRS resource allocation, both Scheme 1 and Scheme 2 should be introduced for supporting SL positioning/ranging:
· Scheme 1: Network-centric operation SL-PRS resource allocation (e.g. similar to a legacy Mode 1 solution)
o The network (e.g. gNB, LMF, gNB & LMF) allocates resources for SL-PRS.
· Scheme 2: UE autonomous SL-PRS resource allocation (e.g. similar to legacy Mode 2 solution)
o At least one of the UE(s) participating in the sidelink positioning operation allocates resources for SL-PRS
Agreement
With regards to the SL Positioning resource allocation, one of the following alternatives should be introduced for supporting SL positioning/ranging:
R1-2207974 Moderator Summary #3 on potential solutions for SL positioning Moderator (Qualcomm)
Agreement
For the content of the sidelink positioning measurement report, potential elements may include at least the following:
· One or more sidelink positioning measurement(s)
· Timestamp(s) associated with a sidelink positioning measurement
· Quality metric(s) associated with a sidelink positioning measurement
· Identification Information for a sidelink positioning measurement
· FFS any detail for the above
Agreement
For the sequence of the new reference signal for SL positioning/ranging, down select between Alt 1 and Alt 2:
Agreement
With regards to the frequency domain pattern, a Comb-N SL-PRS occupying M symbol(s) design should be introduced for the support of NR SL positioning
· Note: there could be multiple values for M, N
Regarding Scheme 2 SL-PRS resource allocation, study at least the following aspects:
· Resource selection mechanism for SL-PRS
· Inter-UE coordination
· Aspects for congestion control mechanisms for SL-PRS
R1-2208186 Moderator Summary #4 on potential solutions for SL positioning Moderator (Qualcomm)
Agreement
· With regards to the configuration/activation/deactivation/triggering of SL-PRS, Option 3 from the previous corresponding RAN1 #109 agreement will not be considered further.
· With regards to reservation of SL-PRS, it can be considered based on the Option 1 or Option 2 from the previous corresponding RAN1 #109 agreement.
Agreement
With regards to the frequency domain pattern for multi-symbol SL-PRS, prioritize partially and fully staggered SL-PRS.
· Note: this does not preclude comb N=1
· FFS: single symbol SL-PRS, if supported
R1-2205869 Error source for NR RAT-dependent positioning Huawei, HiSilicon
R1-2205902 Discussion on integrity of RAT dependent positioning ZTE
R1-2205995 Discussion on error sources for RAT-dependent positioning Spreadtrum Communications
R1-2206047 Discussion on solutions for integrity of RAT dependent positioning vivo
R1-2206125 Considerations on Integrity for RAT dependent positioning Sony
R1-2206273 Discussions on Integrity for NR Positioning OPPO
R1-2206406 Discussion on solutions for integrity of RAT dependent positioning techniques CATT
R1-2206490 Views on solutions for integrity of RAT-dependent positioning techniques Nokia, Nokia Shanghai Bell
R1-2206499 Integrity aspects for RAT-dependent positioning Lenovo
R1-2206650 Error source for NR RAT-dependent positioning integrity Xiaomi
R1-2206832 Discussion on Integrity of RAT Dependent Positioning Samsung
R1-2206918 Discussion on integrity for RAT-dependent positioning CMCC
R1-2207088 Discussion on integrity for RAT dependent positioning techniques InterDigital, Inc.
R1-2207239 Integrity for RAT dependent positioning Qualcomm Incorporated
R1-2207284 Views on solutions for integrity of RAT dependent positioning techniques Sharp
R1-2207412 Discussion on solutions for integrity of RAT dependent positioning techniques NTT DOCOMO, INC.
R1-2207621 Error Sources characterization for integrity of RAT dependent positioning techniques Ericsson
R1-2207744 FL summary #1 on integrity of RAT dependent positioning techniques Moderator (InterDigital)
From Monday session
Agreement
· For LMF-based positioning integrity mode, at least the followings are error sources for timing related measurements :
o RSTD measurement is an error source for DL-TDOA
o RTOA measurement is an error source for UL-TDOA
o UE Rx-Tx time difference measurement is an error source for Multi-RTT
o gNB Rx-Tx time difference measurement is an error source for Multi-RTT
· FFS : Model of the error source (e.g., distribution, mean and/or standard deviation for integrity overbounding model, range)
· Note : Definition of “LMF-based positioning integrity mode” can be found in Table 9.4.1.1.1 in TR 38.857
Agreement
· For LMF-based positioning integrity mode, at least angle of arrival measurement is an error source for UL-AoA
· FFS : Model of the error source (e.g., distribution, mean and/or standard deviation for integrity overbounding model, range)
· FFS: The error can be expressed as the error of the AoA/ZoA in LCS or GCS or the error of a defined function of AoA/ZoA in LCS.
· Note : Definition of “LMF-based positioning integrity mode” can be found in Table 9.4.1.1.1 in TR 38.857
R1-2207922 FL summary #2 on integrity of RAT dependent positioning techniques Moderator (InterDigital)
Agreement
For UE-based positioning integrity mode, at least the following are error sources in assistance data :
Agreement
For LMF-based positioning integrity mode, ARP location (e.g., ARPLocationInformation in TS 38.455) is an error source for UL-AoA.
Agreement
For LMF-based positioning integrity mode, at least inter-TRP synchronization is an error source for UL-TDOA.
Agreement
Study the distribution of RSTD, RTOA and UE/gNB Rx-Tx time measurement error considering the following aspects:
Note : it is encouraged to provide the evaluation assumptions used by companies (e.g., requirements in TS 38.101, TS 38.104, TS 38.133, evaluation assumptions in TR 38.857, LOS/NLOS probability, measurement algorithm) and results (e.g., error histogram) if evaluation is used to determine the distribution, mean and standard deviation or range of values of an error source.
R1-2208189 FL summary #3 on integrity of RAT dependent positioning techniques Moderator (InterDigital)
Agreement
Study the distribution of arrival measurement error focusing on the following aspects
Note: It is encouraged to provide evaluation assumptions (e.g., requirements in TS 38.101, TS 38.104, TS 38.133, evaluation assumptions in TR 38.857, LOS/NLOS probability, measurement algorithm) and results (e.g., error histogram) if evaluation is used to determine the distribution, mean and standard deviation or range of values of an error source.
R1-2205870 Evaluation and solutions for NR carrier phase positioning Huawei, HiSilicon
R1-2205903 Discussion on carrier phase measurement based positioning ZTE
R1-2206048 Discussion on carrier phase measurement enhancements vivo
R1-2206227 Solutions for Integer Ambiguity, TRP synchronization and Vertical Positioning Locaila
R1-2206274 Discussions on Carrier Phase Measurement for NR Positioning OPPO
R1-2206407 Discussion on improved accuracy based on NR carrier phase measurement CATT
R1-2206491 Views on improved accuracy based on NR carrier phase measurement Nokia, Nokia Shanghai Bell
R1-2206500 On NR carrier phase measurements Lenovo
R1-2206590 Improved positioning accuracy with NR carrier phase measurements Intel Corporation
R1-2206651 Improved accuracy based on NR carrier phase measurement Xiaomi
R1-2206694 Discussion on improved accuracy based on NR carrier phase measurement China Telecom
R1-2206919 Discussion on carrier phase positioning CMCC
R1-2207090 Discussion on positioning based on NR carrier phase measurement InterDigital, Inc.
R1-2207126 NR carrier phase measurements for positioning Fraunhofer IIS, Fraunhofer HHI
R1-2207240 Phase Measurements in NR Positioning Qualcomm Incorporated
R1-2207285 Views on improved accuracy based on NR carrier phase measurement Sharp
R1-2207413 Discussion on improved accuracy based on NR carrier phase measurement NTT DOCOMO, INC.
R1-2207480 On carrier phase measurement MediaTek Inc.
R1-2207622 Improved accuracy based on NR carrier phase measurement Ericsson
R1-2207710 Discussion on OFDM based carrier phase measurement in NR LG Electronics (rev of R1-2207360)
R1-2207742 Discussion on NR Carrier Phase Measurement Samsung (rev of R1-2206833)
R1-2207690 FL Summary for improved accuracy based on NR carrier phase measurements Moderator (CATT)
From Tuesday session
Agreement
Endorse the templates in section 17 under (H)(Round 1) Proposal 17-1 in R1-2207690 to collect carrier-phase based positioning simulation results, with the following notes:
R1-2207691 FL Summary #2 for improved accuracy based on NR carrier phase measurements Moderator (CATT)
Agreement
In the evaluation of NR carrier phase positioning, the following frequency errors can be considered, which are modeled independently for each UE and each TRP:
· Initial Residual CFO (is the same for one measurement instances [or multiple phase measurement instances]):
o Ideal: 0 (UE/TRP)
o Practical: uniform distribution within
§ [-30, +30] Hz (FR1, UE), [-100, +100] Hz (FR1, UE),
§ [-120, +120] Hz (FR2, UE), [-400, +400] Hz (FR2, UE),
§ [-10, +10] Hz (for each TRP, FR1),
§ [-40, +40] Hz (for each TRP, FR2).
· Oscillator-drift (is the same for one or multiple phase measurement instances for positioning fix):
o Ideal: 0 (UE/TRP)
o Practical: uniform distribution within [-0.1, 0.1] ppm (UE), [-0.02, +0.02] ppm (each TRP) within measurement duration
· Note: The Doppler frequency can be determined based on the UE speed in the evaluation assumption.
Agreement
In the evaluation of NR carrier phase positioning, the offset between the initial phase of the transmitter and the initial phase of the receiver can be modeled as a random variable uniformly distributed within [0, X].
Agreement
In the evaluation of NR carrier phase positioning, the antenna reference point (ARP) location error of a TRP can be modeled as follows:
· Ideal: no ARP error
· Practical: a zero-mean, truncated Gaussian distribution with zero mean and standard deviation of T=[1, 5] cm truncated to 2T in each of (x, y, z) direction
R1-2208206 FL Summary #3 for improved accuracy based on NR carrier phase measurements Moderator (CATT)
Agreement
In the evaluation of NR carrier phase positioning, the following the UE/TRP antenna phase center offset (PCO) model can be considered as the starting point:
dPCO = a * dPhi + w
where
Agreement
For the evaluation of NR carrier phase positioning, UE position can be calculated by the use of the carrier phase measurements obtained at the M sequential time instances, where
Agreement
Further evaluate the following multipath mitigation methods for the carrier phase positioning, which include, but are not limited to, the following:
Including discussions on requirements, evaluations, and potential enhancements.
R1-2205871 Evaluation and solutions for LPHAP Huawei, HiSilicon
R1-2205904 Discussion on low power high accuracy positioning ZTE
R1-2205996 Discussion on evaluation on LPHAP Spreadtrum Communications
R1-2206049 Discussion on Low Power High Accuracy Positioning vivo
R1-2206275 Disucssion on Low Power High Accuracy Positioning OPPO
R1-2206408 Discussion on Low Power High Accuracy Positioning CATT
R1-2206492 Views on LPHAP Nokia, Nokia Shanghai Bell
R1-2206501 LPHAP considerations Lenovo
R1-2206591 Discussion on power saving evaluation and techniques for LPHAP Intel Corporation
R1-2206652 Discussion on Low Power High Accuracy Positioning Xiaomi
R1-2206834 Discussion on LPHAP Samsung
R1-2206920 Discussion on low power high accuracy positioning CMCC
R1-2206921 Summary for low power high accuracy positioning Moderator (CMCC)
R1-2207091 Discussions on Low Power High Accuracy Positioning (LPHAP) techniques InterDigital, Inc.
R1-2207241 Requirements, Evaluations, Potential Enhancements for Low Power High Accuracy Positioning Qualcomm Incorporated
R1-2207286 Views on low power high accuracy positioning Sharp
R1-2207361 Discussion on LPHAP in idle/inactive state LG Electronics
R1-2207414 Discussion on Low Power High Accuracy Positioning NTT DOCOMO, INC.
R1-2207623 Evaluations for Low Power High Accuracy Positioning Ericsson
R1-2206921 Summary for low power high accuracy positioning Moderator (CMCC)
From Tuesday session
Agreement
In the LPHAP evaluation, adopt the following model to convert the relative power unit to the battery life:
· Alt. 1: battery life is used as the metric to identify the gap
o K is an implementation factor, K = 1 (baseline); K = 0.5, 2, 4 (optional)
· Note: The definition of the notations will be captured in the updates of TR.
· Note: The voltage is assumed to be the same for the reference device and the LPHAP device.
Agreement
· In the LPHAP evaluation, adopt the following example parameter values in the conversion model to evaluate the battery life:
o For the reference device in the conversion model:
|
C1 (mAh) |
T1 (hour) |
X |
reference traffic type |
|
4500 |
12 |
20% |
FTP (model 3) |
o
For the LPHAP device,
consider 2 types in the conversion model:
|
LPHAP device |
C2 (mAh) |
T2req (month) |
|
Type A (baseline) |
800 |
6~12 |
|
Type B (optional) |
4500 |
6~12 |
· Note: As the reference device and LPHAP device characteristics, and therefore the parameter values of the model for determining battery life, is dependent on implementation factors, manufacturer, design options and cost options, it is up to individual company to evaluate the optional K values, and report the corresponding parameter values.
Agreement
In the LPHAP evaluation, adopt the example value of relative power unit of the reference device P1 = 50 to further align the battery life among companies.
Agreement
For the purpose of LPHAP evaluation, an ultra-deep sleep state is considered. The following options of the power consumption model of the ultra-deep sleep state can be further discussed:
· Option 1:
o The relative power unit: 0.015
o Additional transition energy: 2000
o Total transition time: 400ms
· Option 2:
o The relative power unit: 0.01
o Additional transition energy: 450;
o Total transition time: 25ms
o FFS: restrictions in processing associated with option 2 after the UE comes out of ultra-deep sleep state
· Notes: the values above can be further discussed
Agreement
For option 1 in the agreement above, the value of additional transition energy is changed to “a value between 2000 and 20000”. FFS which value.
Agreement
· For the purpose of LPHAP evaluation, the following assumptions on eDRX configuration and/or paging reception can be optionally considered:
o The eDRX cycle to evaluate: 20.48s; 30.72s;
o For paging reception:
§ 1 paging occasion is included in one eDRX cycle
§ 10% paging rate
o No paging reception can be optionally evaluated;
o 1 DL PRS and/or UL SRS for positioning occasion per 1 eDRX cycle
§ Minimizing the gap between PRS measurement, SRS transmission and/or measurement reporting with paging monitoring in time domain can be evaluated.
R1-2207993 Summary for low power high accuracy positioning Moderator (CMCC)
Agreement
The tables to collect evaluation results from each source in section 3.3.2 of R1-2207993 are endorsed.
Agreement
Capture the following in TR as an observation:
· Evaluations of baseline Rel-17 RRC_INACTIVE state positioning with the evaluation assumptions agreed for the study show that the power consumption on deep sleep state accounts for the highest proportion in the total power.
Final summary in R1-2207994.
Including performance evaluation of existing positioning procedures and measurements with RedCap UEs. The result of the evaluation will be used to assess the necessity of enhancements and, if needed, identify enhancements.
R1-2205872 Discussion on RedCap positioning Huawei, HiSilicon
R1-2205905 Discussion on Positioning for RedCap UE ZTE
R1-2206050 Discussion on positioning for RedCap UEs vivo
R1-2206126 Discussion on positioning for RedCap UEs Sony
R1-2206276 Discussion on Positioning for RedCap Ues OPPO
R1-2206426 Discussion on positioning for RedCap UEs CATT
R1-2206473 Discussion on positioning support for RedCap UEs NEC
R1-2206493 Views on Positioning for RedCap UEs Nokia, Nokia Shanghai Bell
R1-2206502 Positioning for RedCap devices Lenovo
R1-2206592 Positioning for RedCap UEs Intel Corporation
R1-2206835 Discussion on Positioning for RedCap UEs Samsung
R1-2206922 Discussion on RedCap positioning CMCC
R1-2207092 Discussions on positioning for RedCap UEs InterDigital, Inc.
R1-2207242 Positioning for Reduced Capabilities UEs Qualcomm Incorporated
R1-2207287 Views on positioning for RedCap Ues Sharp
R1-2207342 Discussions on Positioning for RedCap Ues Apple
R1-2207362 Discussion on positioning support for RedCap Ues LG Electronics
R1-2207415 Discussion on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2207482 The potential solutions for RedCap UEs for positioning MediaTek Inc.
R1-2207624 Considerations for RedCap Positioning Ericsson
R1-2207749 Feature Lead Summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
From Wed session
Agreement
For the purpose of the Rel-18 study
· The target accuracy requirements for RedCap UEs for commercial use cases are defined as follows:
o Indoor and outdoor
§ Horizontal position accuracy (< 3 m) for 90% of UEs
§ Vertical position accuracy (< 3 m) for 90% of UEs
· The target accuracy requirements for RedCap UEs for IIoT use cases are defined as follows:
o Horizontal position accuracy (<1 m) for 90% of UEs
o Vertical position accuracy (< 3 m) for 90% of UEs
· Note: the requirements may not be met in all scenarios and use cases
Agreement
CDF values for evaluations of Redcap UE Positioning scenarios are derived based on:
Agreement
The following table is endorsed to capture the evaluation scenarios and parameters in the evaluation results section of the TR:
Table 3.2-2 evaluation scenarios and parameters template
|
Parameter |
Case XYZ (channel model, FRx) |
|
Scenario (baseline, otherwise state any modifications) |
|
|
Carrier frequency |
|
|
Subcarrier spacing |
|
|
Reference Signal Transmission Bandwidth |
|
|
Reference Signal Physical Structure and Resource Allocation (RE pattern) (reference to figure in contribution) |
|
|
Reference signal (type of sequence, number of ports, …) |
|
|
Number of sites |
|
|
Number of symbols used per occasion |
|
|
number of occasions used per positioning estimate |
|
|
Power-boosting level |
|
|
Uplink power control (applied/not applied) |
|
|
interference modelling (ideal muting, or other) |
|
|
Description of Measurement Algorithm (e.g. super resolution, interference cancellation, ….) |
|
|
Description of positioning technique / applied positioning algorithm (e.g. Least square, Taylor series, etc) |
|
|
Network synchronization assumptions |
|
|
UE/gNB RX and TX timing error |
|
|
Beam-related assumption (beam sweeping / alignment assumptions at the tx and rx sides) |
|
|
Precoding assumptions (codebook, nrof antenna elements used, etc) |
|
|
UE antenna configuration |
|
|
Number of UE branches |
|
|
Description of enhancement solutions, if any |
|
|
gNB antenna configuration |
|
|
UE noise figure |
|
|
UE antenna height |
|
|
gNB antenna height |
|
|
Additional notes, if any |
|
Agreement
Endorse the templates in section 7 in R1-2207749 to collect RedCap UE positioning simulation results, with the following notes:
Agreement
For the evaluation of redcap UEs in the RMa scenarios, companies should report their evaluations parameters with their results.
Agreement
The potential benefits and performance gains of frequency hopping of the DL PRS and UL SRS can be investigated in release 18, which may take into account at least the following:
· The impact of Doppler, phase offset, timing offset, power imbalance among hops
· RedCap UE capability and complexity considerations
· Impact of RF retuning during frequency hopping
· Details of frequency hopping (including Tx hopping and/or Rx hopping, BWP switching) for the study are FFS
Please refer to RP-222616 for detailed scope of the SI.
R1-2210692 Session notes for 9.5 (Study on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
R1-2210037 Work Plan for Study Item on Expanded and Improved NR Positioning Intel Corporation, CATT, Ericsson
R1-2210233 Draft TR 38.859 v020: Study on expanded and improved NR positioning Intel, CATT, Ericsson
R1-2210672 Draft TR 38.859 v020: Study on expanded and improved NR positioning Intel, CATT, Ericsson
[post-110bis-e-02] R18 Positioning TR update by Oct 24 - Debdeep (Intel)
/To be handled using NWM – please use 110bis-e-NWM-R18-Pos-01 as the document name
R1-2208338 LS on Terminology Alignment for Ranging/Sidelink Positioning SA2, Xiaomi
[110bis-e-R18-Pos-01] – Qun Zhao (Xiaomi)
Email discussion on incoming SA2 LS in R1-2208338 by October 14
R1-2210443 Moderator summary on discussion on incoming SA2 LS in R1-2208338 on terminology alignment Moderator (Xiaomi)
R1-2210550 [Draft] Reply LS on Terminology Alignment for Ranging/Sidelink Positioning Xiaomi
Decision: As per email decision posted on Oct 15th, the draft reply LS is endorsed. Final version is approved in R1-2210567.
Including evaluation methodology and performance evaluation results
R1-2208363 Evaluation of SL positioning Nokia, Nokia Shanghai Bell
R1-2208452 SL positioning evaluations Huawei, HiSilicon
R1-2208647 Evaluation of sidelink positioning performance vivo
R1-2208820 Evaluation methodology and results of SL positioning OPPO
R1-2208980 Evaluation methodology and performance evaluation for SL positioning CATT, GOHIGH
R1-2209104 Discussion on evaluation of SL positioning Sony
R1-2209212 Discussion on evaluation of SL positioning ZTE, CMCC
R1-2209290 Discussion on evaluation of sidelink positioning xiaomi
R1-2209392 SL Positioning Evaluation and Performance Lenovo
R1-2209482 Discussion on evaluation of SL positioning LG Electronics
R1-2209486 Evaluation results for SL positioning InterDigital, Inc.
R1-2209735 Discussion on Evaluation for SL Positioning Samsung
R1-2209782 SL positioning scenarios Sharp
R1-2209989 Sidelink Positioning Evaluation Assumptions and Results Qualcomm Incorporated
R1-2210038 Evaluation of SL positioning Intel Corporation
R1-2210111 Evaluation results and observations on V2X and IIoT use case for sidelink positioning CEWiT
R1-2210174 Evaluation of NR SL positioning and ranging Ericsson
[110bis-e-R18-Pos-02] – Chuangxin (ZTE)
Email discussion on evaluation of SL positioning by October 19
- Check points: October 14, October 19
R1-2209459 Summary #1 for SL positioning evaluation Moderator (ZTE)
From Oct 10th GTW session
Observation
The performance analysis for Rel-18 SL positioning shows that, with increasing of bandwidth of SL PRS, the positioning accuracy improves for both absolute positioning and relative positioning/ranging for all evaluated scenarios.
Observation
The performance analysis for Rel-18 SL positioning shows that different SL positioning methods can be used to determine absolute position of a target UE:
· Simulation results based SL-TDOA were provided in contributions from 10 sources ([Nokia 1], [OPPO 4], [CATT, GOHIGH 5], [Sony 6], [ZTE,CMCC 7], [Lenovo 9], [LG 10], [InterDigital 11], [Intel 15], [CEWiT 16])
· Simulation results based on SL-RTT (multi-RTT) were provided in contributions from 6 sources ([Huawei 2], [vivo 3], [LG 10], [InterDigital 11], [Qualcomm 14], [Samsung 12])
· Simulation results based on two anchors SL-AOA and single anchor SL-TOA+AOA were provided in contribution from 1 source ( [Lenovo 9])
Note: at least the number of sources and the references can be further updated in next meeting depending on companies’ update of simulation results.
Decision: As per email decision posted on Oct 15th,
Observation
The performance analysis for Rel-18 SL positioning shows that, SL positioning methods can be used for relative positioning/ ranging between UEs. For relative positioning/ranging positioning accuracy,
Note: at least the number of sources and the references can be further updated in next meeting depending on companies’ update of simulation results.
R1-2209460 Summary #2 for SL positioning evaluation Moderator (ZTE)
R1-2210579 Summary #3 for SL positioning evaluation Moderator (ZTE)
From Oct 17th GTW session
Observation
For V2X use case in highway scenario, 13 sources ([Huawei 2], [vivo 3], [OPPO 4], [CATT,GOHIGH 5], [Sony 6], [ZTE,CMCC 7], [Lenovo 9], [LG 10], [Samsung 12], [Qualcomm 14], [Intel 15], [CEWiT 16], [Ericsson 17]) provide simulation results for FR1, and 1 source ([CEWiT 16]) provides simulation results for FR2.
Observation
For V2X use case in Urban grid scenario, 10 sources ([Huawei 2], [vivo 3], [OPPO, 4], [CATT,GOHIGH 5], [Sony 6], [ZTE,CMCC 7], [xiaomi 8], [Lenovo 9], [Intel 15], [CEWiT 16]) provide simulation results for FR1, and 1 source ([CEWiT 16]) provide simulation results for FR2.
Observation
Simulation results in contributions from 7 sources ([Huawei 2], [vivo 3], [CATT,GOHIGH 5], [ZTE,CMCC 7], [xiaomi 8], [LG 10], [Intel 15]) show that relative horizontal accuracy and/or distance accuracy of ranging performance improves with X value decreasing, where X is the maximum distance between two UEs for performing relative positioning or ranging.
Note: the above observations can be further updated in next meeting depending on companies’ new/update of simulation results, including editorial modifications, X values, replacing sources by references, additional sources and other revisions.
R1-2208364 Potential solutions for SL positioning Nokia, Nokia Shanghai Bell
R1-2208372 Potential solutions for sidelink positioning FUTUREWEI
R1-2208453 Discussion on SL positioning solutions Huawei, HiSilicon
R1-2208558 Discussion on potential solutions for SL positioning Spreadtrum Communications
R1-2208648 Discussion on potential solutions for sidelink positioning vivo
R1-2208773 Discussion on potential solutions for sidelink positioning China Telecom
R1-2208821 Discussion on potential solutions for SL positioning OPPO
R1-2208981 Discussion on potential solutions for SL positioning CATT, GOHIGH
R1-2209058 Potential solutions for SL positioning Intel Corporation
R1-2209105 Consideration on potential solutions for SL positioning Sony
R1-2209151 Discussion on potential solutions for SL positioning NEC
R1-2209213 Discussion on potential solutions for SL positioning ZTE
R1-2209291 Discussion on sidelink positioning solutions xiaomi
R1-2209341 Discussion on potential solutions for SL positioning CMCC
R1-2209393 Potential SL Positioning Solutions Lenovo
R1-2209483 Discussion on potential solutions for SL positioning LG Electronics
R1-2209487 Potential solutions for SL positioning InterDigital, Inc.
R1-2209533 Potential solutions for SL positioning Faunhofer IIS, Fraunhofer HHI
R1-2209589 Discussions on Potential solutions for SL positioning Apple
R1-2209675 Discussion on potential solutions for SL positioning DENSO CORPORATION
R1-2209736 Discussion on Potential Solutions for SL Positioning Samsung
R1-2209783 Views on potential solutions for SL positioning Sharp
R1-2209797 Discussion on sidelink positioning ASUSTeK
R1-2209907 Discussion on potential solutions for SL positioning NTT DOCOMO, INC.
R1-2209990 Potential Solutions for Sidelink Positioning Qualcomm Incorporated
R1-2210097 The potential solutions for sidelink positioning MediaTek Inc.
R1-2210102 Considerable solutions on sidelink positioning in NR ITL
R1-2210112 Discussion on enhancements for sidelink based positioning CEWiT
R1-2210175 On potential solutions for SL positioning Ericsson
[110bis-e-R18-Pos-03] – Alex (Qualcomm)
Email discussion on potential solutions for SL positioning by October 19
- Check points: October 14, October 19
R1-2210341 Moderator Summary #1 on potential solutions for SL positioning Moderator (Qualcomm Incorporated)
From Oct 10th GTW session
Agreement
Agreement
For the study of SL-AoA positioning method,
Agreement
With regards to SL-TDOA positioning method for SL-only positioning,
R1-2210381 Moderator Summary #2 on potential solutions for SL positioning Moderator (Qualcomm Incorporated)
From Oct 13th GTW session
Agreement
Decision: As per email decision posted on Oct 15th,
Agreement
Regarding Scheme 1 SL-PRS resource allocation, a transmitting UE receives a SL-PRS resource allocation signaling from the network. Consider one or more of the following options:
R1-2210522 Moderator Summary #3 on potential solutions for SL positioning Moderator (Qualcomm Incorporated)
From Oct 17th GTW session
Agreement
For the sequence of the new reference signal for SL positioning/ranging, use
Agreement
From RAN1 perspective, the following cast types of SL-PRS transmission can be introduced for SL positioning: Unicast, Groupcast (not including many to one)
R1-2210598 Moderator Summary #4 on potential solutions for SL positioning Moderator (Qualcomm Incorporated)
From Oct 19th GTW session
Agreement
With regards to the frequency and time domain pattern of a SL-PRS resource within a slot has the following characteristics:
Agreement
For a dedicated resource pool for SL positioning,
Agreement
With regards to the SL Positioning resource allocation, for SL Positioning resource (pre-)configuration in a shared resource pool with Rel-16/17/18 sidelink communication (if supported), backward compatibility with legacy Rel-16/17 UEs should be ensured.
Agreement
With regards to SL signaling of the reservation/indication of SL-PRS resource(s) for dedicated resource pool and shared resource pool (if supported) for positioning:
Decision: As per email decision posted on Oct 20th,
Agreement
With regards to the Positioning methods supported using SL-PRS measurements
Agreement
At least for a dedicated resource pool for positioning,
Agreement
Study further the granularity of time-domain resource allocation for SL-PRS transmission.
Agreement
With regards to the SL-PRS time domain behavior, at least study the following behaviors from Tx UE perspective:
R1-2208454 Error source for NR RAT-dependent positioning Huawei, HiSilicon
R1-2208480 Discussion on integrity of RAT dependent positioning BUPT (Withdrawn)
R1-2208516 Discussion on integrity of RAT dependent positioning BUPT
R1-2208649 Discussion on solutions for integrity of RAT-dependent positioning vivo
R1-2208735 Views on solutions for integrity of RAT-dependent positioning techniques Nokia, Nokia Shanghai Bell
R1-2208800 Discussions on Integrity for NR Positioning OPPO
R1-2208982 Discussion on solutions for integrity of RAT dependent positioning techniques CATT
R1-2209002 Discussion on error sources for RAT dependent positioning Spreadtrum Communications
R1-2209106 Discussion on Error Sources for Integrity of NR Positioning Sony
R1-2209214 Discussion on integrity of RAT dependent positioning ZTE
R1-2209292 Error source for NR RAT-dependent positioning integrity xiaomi
R1-2209342 Discussion on integrity for RAT-dependent positioning CMCC
R1-2209394 Integrity aspects for RAT-dependent positioning Lenovo
R1-2209488 Discussion on integrity for RAT dependent positioning techniques InterDigital, Inc.
R1-2209737 Discussion on Integrity of RAT Dependent Positioning Samsung
R1-2209784 Views on solutions for integrity of RAT dependent positioning techniques Sharp
R1-2209908 Discussion on solutions for integrity of RAT dependent positioning techniques NTT DOCOMO, INC.
R1-2209991 Integrity for RAT dependent positioning Qualcomm Incorporated
R1-2210176 Error Sources characterization for integrity of RAT dependent positioning techniques Ericsson
[110bis-e-R18-Pos-04] – Fumihiro (InterDigital)
Email discussion on solutions for integrity of RAT dependent positioning techniques by October 19
- Check points: October 14, October 19
R1-2210274 FL summary #1 on integrity of RAT dependent positioning techniques Moderator (InterDigital, Inc.)
From Oct 10th GTW session
Agreement
Agreement
Agreement
Agreement
Decision: As per email decision posted on Oct 15th,
Agreement
Capture the following into the TR
Agreement
Agreement
Agreement
R1-2210428 FL summary #2 on integrity of RAT dependent positioning techniques Moderator (InterDigital, Inc.)
From Oct 17th GTW session
Agreement
Agreement
· Study to determine whether DL PRS RSRP/RSRPP measurement is an error source for DL-AoD, focusing at least on the following aspect
· Impact of RSRP/RSRPP measurement on positioning accuracy
· FFS : Model of the error source (e.g., distribution, mean and/or standard deviation for integrity overbounding model, range)
Decision: As per email decision posted on Oct 20th,
· Note: Definition of “LMF-based positioning integrity mode” can be found in Table 9.4.1.1.1 in TR 38.857
Final summary in R1-2210633.
R1-2208455 Discussion on NR carrier phase positioning Huawei, HiSilicon
R1-2208650 Discussion on carrier phase measurement enhancements vivo
R1-2208736 Views on improved accuracy based on NR carrier phase measurement Nokia, Nokia Shanghai Bell
R1-2208774 Discussion on improved accuracy based on NR carrier phase measurement China Telecom
R1-2208801 Discussions on Carrier Phase Measurement for NR Positioning OPPO
R1-2208983 Discussion on improved accuracy based on NR carrier phase measurement CATT
R1-2209059 Carrier phase positioning in NR systems Intel Corporation
R1-2209152 Discussion on NR carrier phase positioning NEC
R1-2209215 Discussion on carrier phase measurement based positioning ZTE
R1-2209293 Improved accuracy based on NR carrier phase measurement xiaomi
R1-2209343 Discussion on carrier phase positioning CMCC
R1-2209395 On NR carrier phase measurements Lenovo
R1-2209489 Discussion on positioning based on NR carrier phase measurement InterDigital, Inc.
R1-2209534 NR carrier phase measurements for positioning Faunhofer IIS, Fraunhofer HHI
R1-2209543 Discussion on double difference method and gNB synchronization Locaila
R1-2209546 Views on NR carrier phase measurement for positioning accuracy enhancement IIT Kanpur, CEWiT
R1-2209738 Discussion on NR Carrier Phase Measurement Samsung
R1-2209785 Views on improved accuracy based on NR carrier phase measurement Sharp
R1-2209805 Discussion on OFDM based carrier phase measurement in NR LG Electronics
R1-2209909 Discussion on improved accuracy based on NR carrier phase measurement NTT DOCOMO, INC.
R1-2209992 Phase Measurements in NR Positioning Qualcomm Incorporated
R1-2210099 On NR carrier phase measurement MediaTek Inc.
R1-2210177 Improved accuracy based on NR carrier phase measurement Ericsson
[110bis-e-R18-Pos-05] – Ren (CATT)
Email discussion on improved positioning accuracy based on NR carrier phase measurement by October 19
- Check points: October 14, October 19
R1-2210267 FL Summary #1 for improved accuracy based on NR carrier phase measurements Moderator (CATT)
From Oct 11th GTW session
Agreement
The existing DL PRS and UL SRS for positioning can be re-used as the reference signals to enable positioning based on NR carrier phase measurements for both UE-based and UE-assisted positioning.
Agreement
For UE-assisted NR carrier phase positioning, at least consider the following options
· the difference between the carrier phase measured from the DL PRS signal(s) of the target TRP and the carrier phase measured from the DL PRS signal(s) of the reference TRP.
· the carrier phase measured from the DL PRS signal(s) of a TRP
Agreement
Make the following modification to the previous agreement on the initial phase model with an additional note:
R1-2210268 FL Summary #2 for improved accuracy based on NR carrier phase measurements Moderator (CATT)
From Oct 17th GTW session
Agreement
Further study the benefits of using the carrier phase measurements of multiple DL positioning frequency layers for NR carrier phase positioning, which may include the impact of the time gap between the carrier phase measurements of multiple DL PFLs.
Decision: As per email decision posted on Oct 17th,
Agreement
For UL UE-assisted NR carrier phase positioning, at least consider the carrier phase measured from the UL SRS for positioning purpose.
· Note: The use of MIMO SRS for positioning purpose is transparent to UE.
Agreement
Capture the following TP into TR 38.859 as a conclusion (for Section 6.3.1):
· The impact of multipath/NLOS on NR carrier phase positioning is evaluated during the study item. Based on the study, it is concluded that multipath/NLOS deteriorates the performance of carrier phase positioning and it is necessary to consider multipath mitigation for NR carrier phase positioning.
· The evaluation results for the impact of the multipath/NLOS on NR carrier phase positioning will be presented in Section 6.3.2.
Agreement
Add the following note to the previous agreement on error modelling of the initial phase:
· Note: The initial phases of a transmitter for different carriers can be assumed to be independent of each other. Similarly, the initial phases of a receiver for different carriers can be assumed to be independent of each other.
Agreement
Add a row of "PRU assumptions" in Table B.4.X.1-1: NR carrier phase positioning enhancements – evaluation scenarios and parameters” in Draft TR 38.859.
· Note: PRU deployment assumptions may include the assumptions of the number of PRUs, the PRU locations and location errors etc.
R1-2210269 FL Summary #3 for improved accuracy based on NR carrier phase measurements Moderator (CATT)
From Oct 19th GTW session
Agreement
Capture the following TP into TR 38.859 as an evaluation observation:
The impact of the initial phases of the transmitter and the receiver on NR carrier phase positioning is evaluated in the study item. The evaluation results from the sources (e.g., Huawei[1], vivo[2], CATT[6], ZTE[9]) show that if the initial phases of the transmitter and the receiver are not eliminated, it is impossible to support centimeter-accuracy positioning.
The effectiveness of using double differential technique with PRU to eliminate the impact of the initial phases of the transmitter and the receiver on NR carrier phase positioning are evaluated in the study item. The evaluation results from the sources (Huawei[1], CATT[6], ZTE[9], Ericsson [23]) show that the initial phases of the transmitter and the receiver can be removed effectively by the double differential technique with the use of the PRU:
· Source [Huawei, 1] shows the positioning accuracy of <1cm (80%) for Inf-SH and < 1cm (50%) for Inf-DH can be reached when the PRU is located within a distance of 5m from the target UE.
· Source [CATT, 6] shows the positioning accuracy of <1cm (80%) for Inf-SH and <1cm (50%) for Inf-DH can be reached under the under condition that the PRU is located a fixed location in LOS of the TRP.
· Source [Ericsson 23] shows that the accuracy of <1cm (50%) when the PRU is located within 1m of the target UE. However, the effectiveness reduces when the PRU is located away from the target UE because the channel conditions of the PRU is different from the target UE.
· Note: in the above results, all other error sources (except initial phase error) were not modelled.
(Not captured in TR) Note: The number of sources and the references, and the observations, can be further updated in next meeting depending on companies’ updates of simulation results.
Agreement
Capture the following TP into TR 38.859 as an evaluation observation (for Section 6.3.2):
The impact of the residual CFOs of the transmitter and the receiver on NR carrier phase positioning are evaluated during the study item.
· The evaluation results from the sources (Huawei[1], ZTE[9]) shows the impact of residual CFOs on carrier phase positioning is negligible.
· The evaluation results from the source (CATT[4]) shows the impact of the residual CFOs on the positioning performance of carrier phase positioning is removed with the use of the double differential technique with the PRU that is located a fixed location in LOS of the TRP.
(Not captured in TR) Note: The number of sources and the references, and the observations, can be further updated in next meeting depending on companies’ updates of simulation results.
Decision: As per email decision posted on Oct 20th,
Capture the following TP into TR 38.859 (Section 6.3.1):
Agreement
Further study the effectiveness of the following multipath mitigation methods for the carrier phase positioning and the potential on the standard work:
Agreement
Further study the following approaches for NR carrier phase positioning, and identify the potential impact on the standard.
· the reporting of the carrier phase-based measurements alone without reporting the existing positioning measurements.
Final summary in R1-2210765.
Including discussions on requirements, evaluations, and potential enhancements.
R1-2208456 Evaluation and solutions for LPHAP Huawei, HiSilicon
R1-2208517 Discussion on Low Power High Accuracy Positioning Quectel
R1-2208559 Discussion on evaluation on LPHAP Spreadtrum Communications
R1-2208651 Discussion on Low Power High Accuracy Positioning vivo
R1-2208737 Views on LPHAP Nokia, Nokia Shanghai Bell
R1-2208802 Discussion on Low Power High Accuracy Positioning OPPO
R1-2210242 Discussion on Low Power High Accuracy Positioning CATT (rev of R1-2208984)
R1-2209060 On Low Power High Accuracy Positioning Intel Corporation
R1-2209107 Discussion on Low Power High Accuracy Positioning Sony
R1-2210398 Discussion on low power high accuracy positioning ZTE (rev of R1-2209216)
R1-2209294 Discussion on Low Power High Accuracy Positioning xiaomi
R1-2209344 Discussion on low power high accuracy positioning CMCC
R1-2209396 LPHAP considerations Lenovo
R1-2209490 Discussions on Low Power High Accuracy Positioning (LPHAP) techniques InterDigital, Inc.
R1-2209739 Discussion on LPHAP Samsung
R1-2209786 Views on low power high accuracy positioning Sharp
R1-2209806 Discussion on LPHAP in idle/inactive state LG Electronics
R1-2209910 Discussion on Low Power High Accuracy Positioning NTT DOCOMO, INC.
R1-2209993 Requirements, Evaluations, Potential Enhancements for Low Power High Accuracy Positioning Qualcomm Incorporated
R1-2210178 Evaluations for Low Power High Accuracy Positioning Ericsson
[110bis-e-R18-Pos-06] – Jingwen (CMCC)
Email discussion on LPHAP by October 19 – Jingwen (CMCC)
- Check points: October 14, October 19
R1-2209345 Summary for low power high accuracy positioning Moderator (CMCC)
From Oct 13th GTW session
Conclusion
· From evaluations for a LPHAP device, RAN1 concludes that the existing Rel-17 positioning for UEs in RRC_INACTIVE state cannot satisfy the target battery life required by LPHAP use case 6 in the majority of the evaluation scenarios that were examined.
· Based on the evaluations, enhancements to meet the target battery life in Rel-18 are necessary.
Observation
Capture the following in TR as an observation:
Chair’s note: references in the above observation are from R1-2209345.
Conclusion
· Evaluations show that UE (re)entering RRC_CONNECTED state to obtain SRS (re)configuration increases power consumption;
· Note: This intermediate conclusion may be updated before capturing it in the TR if new/different evaluations are provided and to add information about the number of sources.
Agreement
· For UL and DL+UL positioning for UEs in RRC_INACTIVE, study the potential benefits and performance gains of enhancements on SRS for positioning in order to avoid frequent SRS (re)configuration, including at least the following:
o The (pre-)configuration of SRS for positioning. FFS details, e.g., signaling and procedure, whether/how it is applicable to an area across multiple cells, consideration of UL overhead/capacity implied by (pre-)configuration and multiple cells, etc;
o SRS for positioning activation/request procedure(s), e.g., network activation of SRS via paging, UE request to obtain/update SRS via RACH-based procedure;
§ FFS: Events of invalidity of SRS configuration to trigger the UE request procedure.
o FFS whether it is applicable to UEs in RRC_IDLE state.
Conclusion
· Evaluations show that extending paging DRX cycles beyond 10.24s provide power saving gains with respect to that with the baseline DRX cycle of 1.28s and is beneficial towards meeting the battery life requirement
· Note: This intermediate conclusion may be updated before capturing it in the TR if new/different evaluations are provided and to add information about the number of sources and to show the achievable gains.
Decision: As per email decision posted on Oct 16th,
Conclusion
· Evaluations show that minimizing gaps between PRS/SRS/paging/reporting/synchronization RS reduces the power consumption;
· Note: This intermediate conclusion may be updated before capturing it in the TR if new/different evaluations are provided and to add information about the number of sources.
R1-2210616 FL summary #2 for low power high accuracy positioning Moderator (CMCC)
From Oct 18th GTW session
Agreement
For the LPHAP study only:
· For the power consumption model of the ultra-deep sleep type, adopt the following option (i.e. revision of option 1 from previous agreement):
o The relative power unit: 0.015
o Additional transition energy: 10000
§ Note: Power consumption analysis from individual companies with additional transition energy of 5000 can be optionally evaluated and captured in the TR.
o Total transition time: 400ms
· Note: Power consumption analysis from individual companies with Option 2 (revised from previous agreement) can be optionally evaluated and captured in the TR.
o Option 2 additional transition energy is revised from 450 to 480.
· Note: No new device type is expected based on ultra-deep sleep power modeling.
Final summary in R1-2210617.
Including performance evaluation of existing positioning procedures and measurements with RedCap UEs. The result of the evaluation will be used to assess the necessity of enhancements and, if needed, identify enhancements.
R1-2208457 Discussion on RedCap positioning Huawei, HiSilicon
R1-2208652 Discussion on positioning for RedCap UEs vivo
R1-2208738 Views on Positioning for RedCap UEs Nokia, Nokia Shanghai Bell
R1-2208803 Discussion on Positioning for RedCap Ues OPPO
R1-2208985 Discussion on positioning for RedCap UEs CATT
R1-2209061 Enhancements for positioning for RedCap UEs Intel Corporation
R1-2209108 Considerations on positioning for RedCap UEs Sony
R1-2209153 Discussion on positioning support for RedCap UEs NEC
R1-2209217 Discussion on Positioning for RedCap UE ZTE
R1-2209346 Discussion on RedCap positioning CMCC
R1-2209397 Positioning for RedCap devices Lenovo
R1-2209491 Discussions on positioning for RedCap UEs InterDigital, Inc.
R1-2209590 Discussions on Positioning for RedCap Ues Apple
R1-2209740 Discussion on Positioning for RedCap UEs Samsung
R1-2209787 Views on positioning for RedCap UEs Sharp
R1-2209807 Discussion on positioning support for RedCap Ues LG Electronics
R1-2209911 Discussion on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2209994 Positioning for Reduced Capability UEs Qualcomm Incorporated
R1-2210179 Positioning for RedCap Ues Ericsson
[110bis-e-R18-Pos-07] – Florent (Ericsson)
Email discussion on positioning for RedCap UEs by October 19
- Check points: October 14, October 19
R1-2210474 Feature Lead Summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
From Oct 13th GTW session
Observation
Capture the following observations in the TR, regarding the baseline performance for positioning of Redcap UEs for IIOT scenarios:
Observation
Capture the following observations in the TR, regarding the baseline performance for positioning of Redcap UEs for commercial scenarios
Observation
Capture the following observations in the TR:
Regarding the performance for positioning of Redcap UEs using frequency hopping in IIoT scenarios, considering phase offset between hops:
Observation
Capture the following observations in the TR:
Regarding the performance for positioning of Redcap UEs using frequency hopping in commercial scenarios, considering phase offset between hops:
Agreement
For the evaluation of TX/RX frequency hopping for positioning of redcap UEs, the value of the gap between two consecutive hops includes at least from 100us to 5ms.
· Companies should indicate if other smaller values are used in their evaluations, and justify the feasibility of smaller values
Agreement
Study the potential enhancement of the UL SRS for positioning to enable Tx frequency hopping, including but not limited to partial overlapping between hops, hopping bandwidth, time gap between frequency hopping.
Agreement
Study the potential enhancement of the DL PRS to enable Tx or Rx frequency hopping, including but not limited to impact on processing capability, hopping bandwidth in the positioning frequency layer, time gap between frequency hopping, measurement period, partial overlapping between hops.
Decision: As per email decision posted on Oct 16th,
Agreement
For the evaluation of TX/RX frequency hopping for positioning of redcap UEs, the value of UE speed includes 3 km/h, 30 km/h, 60km/h.
· Other values are not precluded
R1-2210475 Feature Lead Summary #2 for Positioning for RedCap UEs Moderator (Ericsson)
From Oct 18th GTW session
Conclusion
The evaluation results for positioning for RedCap UEs using carrier phase measurements can be captured in the TR to show whether target requirement of positioning for RedCap UEs can be met or not, but any non-RedCap-specific enhancements regarding CPP should be studied under AI 9.5.2.2 in Rel-18.
· For the modelling of error sources specific to carrier phase measurements, the evaluations assumptions agreed in AI 9.5.2.2 are reused.
· Note: Phase-difference AoD can be included in the evaluations. Support of Phase-difference AoD for CPP should be discussed under AI 9.5.2.2.
Final summary in R1-2210476.
Please refer to RP-222616 for detailed scope of the SI.
R1-2212847 Session notes for 9.5 (Study on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
Endorsed and contents incorporated below.
[111-R18-Pos] – Debdeeep (Intel)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
From Nov 18th session
Email discussion for endorsement of TR38.859 update according to the agreements at RAN1#111 from Nov 28 until Nov 29 - Debdeep (Intel)
From AI 5
R1-2210821 LS on RAN dependency for Ranging/Sidelink Positioning SA2, xiaomi
R1-2212750 Moderator summary 1 on discussion of SA2 LS in R1-2210821 on RAN dependency for Ranging/Sidelink Positioning Moderator(xiaomi)
Decision: From Nov 15th session,
Agreement
RAN1 provides the following feedback on issue 6 with a copy of the 3 RAN1 agreements below:
“RAN1 has agreed to introduce UE autonomous SL-PRS resource allocation (e.g. similar to legacy Mode 2 solution), which can be used in out-of-coverage area. The details are still under discussion in RAN1.”, and include the following RAN1 existing agreements into the reply LS.
|
Agreement With regards to the SL-PRS resource allocation, study the following two schemes: § Scheme 1: Network-centric operation SL-PRS resource allocation (e.g. similar to a legacy Mode 1 solution) o The network (e.g. gNB, LMF, gNB & LMF) allocates resources for SL-PRS § Scheme 2: UE autonomous SL-PRS resource allocation (e.g. similar to legacy Mode 2 solution) o At least one of the UE(s) participating in the sidelink positioning operation allocates resources for SL-PRS o Applicable regardless of the network coverage § FFS: potential mechanisms, if needed, for SL-PRS resource coordination across a number of transmitting UEs (e.g. IUC-like solutions). § Note: Other Schemes are not precluded to be studied § FFS how to handle resource allocation of SL-Positioning measurement report Agreement Regarding SL-PRS resource allocation, both Scheme 1 and Scheme 2 should be introduced for supporting SL positioning/ranging:
Agreement Regarding Scheme 2 SL-PRS resource allocation, study at least the following aspects:
|
R1-2212781 Moderator summary 2 on discussion of SA2 LS in R1-2210821 on RAN dependency for Ranging/Sidelink Positioning Moderator (xiaomi)
Decision: From Nov 16th session,
Agreement
RAN1 provides the following feedback on issue 3:
“RAN1 assumes that any distinction between Assistant UE and anchor UE is transparent to RAN1. The anchor UE selection/reselection have not been discussed in RAN1. Whether/how physical layer measurement results will be used for determination of using assistant UE and the assistant UE selection/reselection will not be discussed in RAN1.”
R1-2212782 [draft] Reply LS on RAN dependency for Ranging/Sidelink Positioning xiaomi
Decision: From Nov 17th session, the draft LS in R1-2212782 is endorsed. The final LS is approved in R1-2212926.
From AI 5
R1-2210824 LS Out on Positioning Reference Units SA2, CATT
R1-2212713 Summary of discussion of reply LS on Positioning Reference Units Moderator (CATT)
Decision: From Nov 15th session,
Agreement
Regarding SA2’s conclusion on PRU, suggest providing the following modification:
· “Based on that information, the PRU could be selected by an LMF to obtain measurements of RAN nodes, or to transmit the reference signals for positioning on Uu and possibly PC5, to help improve location accuracy for all UEs and/or to assist the positioning of specific other UEs”.
Agreement
Regarding SA2’s first question, suggest providing the following response:
· RAN1 suggests SA2 check with RAN2 or RAN3 for the answer.
Agreement
Regarding SA2’s second question, RAN1 responds as follows:
· From RAN1's perspective, a UE (which could be a PRU) that supports SL positioning can be allowed to support the positioning reference signal transmission capability and signal measurement capability on PC5, if the capability is introduced in R18.
Comeback for reply LS
R1-2212714 Draft Reply LS on Positioning Reference Units Moderator (CATT)
Decision: As per decision in Nov 16th session, the draft LS response in R1-2212714 is endorsed with the following revisions:
·
Regarding SA2’s second
question, RAN1 would responds as follows
·
RAN1 kindly
respectfully requests SA2
Final LS is approved in:
R1-2212715 Reply LS on Positioning Reference Units RAN1, CATT
R1-2212950 Summary of offline discussion on bandwidth requirements on SL positioning Moderator (Intel Corporation)
From Nov 18th session
Agreement
Capture the following as part of the Conclusions section of TR 38.859:
Note: The above recommendations are based on the evaluations in licensed and ITS spectra.
Including evaluation methodology and performance evaluation results
R1-2210831 Evaluation of SL positioning Nokia, Nokia Shanghai Bell
R1-2210900 Finalizing SL positioning evaluation Huawei, HiSilicon
R1-2211011 Evaluation of sidelink positioning performance vivo
R1-2211202 Further performance evaluation for SL positioning CATT, GOHIGH
R1-2211267 Discussion on evaluation of SL positioning LG Electronics
R1-2211301 Evaluation of latency requirements for sidelink positioning TOYOTA Info Technology Center
R1-2211368 Discussion on evaluation of sidelink positioning xiaomi
R1-2212739 Evaluations of SL positioning Intel Corporation (rev of R1-2211404)
R1-2211446 Evaluation results for SL positioning OPPO
R1-2211500 Discussion on evaluation of SL positioning ZTE, CMCC
R1-2211615 Evaluation of SL positioning Sony
R1-2211720 Evaluation results for SL positioning InterDigital, Inc.
R1-2211739 SL Positioning Evaluation and Performance Lenovo
R1-2212049 Discussion on Evaluation for SL Positioning Samsung
R1-2212121 Sidelink Positioning Evaluation Assumptions and Results Qualcomm Incorporated
R1-2212379 "Evaluation of SL positioning " Fraunhofer IIS, Fraunhofer HHI
R1-2212427 Evaluation results and observations on V2X and IIoT use case for sidelink positioning CEWiT
R1-2212512 Evaluation of NR SL positioning and ranging Ericsson
R1-2211506 Summary #1 for SL positioning evaluation Moderator (ZTE)
From Nov 15th session
Observation:
Update the observation for V2X use case in highway scenario as follows:
For V2X use case in highway scenario, 14 sources ([Huawei 2], [vivo 3], [OPPO 4], [CATT,GOHIGH 5], [Sony 6], [ZTE,CMCC 7], [Lenovo 9], [LG 10], [Samsung 12], [Fraunhofer 13], [Qualcomm 14], [Intel 15], [CEWiT 16], [Ericsson 17]) provide simulation results for FR1, and 2 sources ([LG 10], [CEWiT 16]) provide simulation results for FR2.
§ and is achieved with 200MHz bandwidth in FR2 in contribution from 1 source ([CEWiT 16])
Observation:
For Public safety use case, 3 sources ([Huawei 2], [ZTE,CMCC 7], [Qualcomm 14]) provide simulation results for FR1.
Observation
For absolute positioning, 5 sources ([Huawei 2], [ZTE,CMCC 7], [Qualcomm 14], [CEWiT 16], [Ericsson 17]) provide simulation results for Joint Uu-SL absolute positioning.
· For V2X use case, 4 sources ([Huawei 2], [ZTE,CMCC 7], [CEWiT 16], [Ericsson 17]) show performance improvement of Joint Uu-SL absolute positioning compared to SL-only positioning
· For V2X use case, 2 sources ([CEWiT 16], [Ericsson 17]) show performance improvement of Joint Uu-SL absolute positioning compared to Uu-only positioning
· For IIOT use case, 3 sources ([Huawei 2], [ZTE,CMCC 7], [CEWiT 16],) show performance improvement of Joint Uu-SL absolute positioning compared to SL-only positioning
· For IIOT use case, 3 sources ([Qualcomm 14], [ZTE,CMCC 7], [CEWiT 16],) show performance improvement of Joint Uu-SL absolute positioning compared to Uu-only positioning
· For Public safety, 1 source ([ZTE,CMCC 7]) show performance improvement of Joint Uu-SL absolute positioning compared to SL-only or Uu-only positioning.
· For commercial use case, 1 source ([ZTE,CMCC 7]) show performance improvement of Joint Uu-SL absolute positioning compared to SL-only positioning.
· For commercial use case, 2 sources ([ZTE,CMCC 7], [Qualcomm 14]) show performance improvement of Joint Uu-SL absolute positioning compared to Uu-only positioning.
Observation
Update the observation for SL absolute positioning methods as follows
The performance analysis for Rel-18 SL positioning shows that different SL positioning methods can be used to determine absolute position of a target UE:
· Simulation results based SL-TDOA were provided in contributions from 12 sources ([Nokia 1], [OPPO 4], [CATT, GOHIGH 5], [Sony 6], [ZTE,CMCC 7], [Lenovo 9], [LG 10], [InterDigital 11], [Samsung 12], [Fraunhofer 13], [Intel 15], [CEWiT 16])
· Simulation results based on SL-RTT (multi-RTT) were provided in contributions from 6 sources ([Huawei 2], [vivo 3], [LG 10], [InterDigital 11], [Qualcomm 14], [Samsung 12])
· Simulation results based on two anchors SL-AOA were provided in contribution from 1 source ([Lenovo 9])
Observation
Update the observation for relative positioning/ranging methods as follows
The performance analysis for Rel-18 SL positioning shows that, SL positioning methods can be used for relative positioning/ ranging between UEs. For relative positioning/ranging positioning accuracy,
· Simulation results based SL-RTT and/or AOA were provided in contributions from 12 sources ([Huawei 2], [vivo 3], [OPPO 4], [CATT, GOHIGH 5], [Sony 6], [ZTE, CMCC 7], [Xiaomi 8], [Lenovo 9], [LG 10], [Qualcomm 14], [Intel 15], [Ericsson 17])
· Results based SL-TDOA were provided in contribution from 1 source ([CEWiT 16])
Observation
Update the observation for relative positioning/ranging with different X values as follows:
Simulation results in contributions from 9 sources ([Huawei 2], [vivo 3], [CATT,GOHIGH 5], [Sony 6], [ZTE,CMCC 7], [xiaomi 8], [Lenovo, 9] [LG 10], [Intel 15]) show that relative horizontal accuracy and/or distance accuracy of ranging performance improves with X value decreasing, where X is the maximum distance between two UEs for performing relative positioning or ranging.
· In some simulation cases, a target requirement may be achieved in condition of a smaller X value but not be achieved in condition of a larger X value for a certain SL PRS bandwidth.
· In some simulation cases, a target requirement may be achieved in condition of a smaller X value and a smaller SL PRS bandwidth, but can be achieved in condition of a larger X value and a larger SL PRS bandwidth.
Observation
Update the observation for V2X use case in Urban grid scenario as follows
For V2X use case in Urban grid scenario, 11 sources ([Huawei 2], [vivo 3], [OPPO, 4], [CATT,GOHIGH 5], [Sony 6], [ZTE,CMCC 7], [xiaomi 8], [Lenovo 9], [Qualcomm 14], [Intel 15], [CEWiT 16]) provide simulation results for FR1, and 1 source ([CEWiT 16]) provide simulation results for FR2.
§ and is achieved with at least 200MHz in FR2 in contribution from 1 source ([CEWiT 16])
· where LOS-only links are used in contribution from (CEWiT 16)
§ and is NOT achieved with at least 200MHz in FR2 in contribution from 1 source ([CEWiT 16])
· where LOS-only links are used in contribution from ([CEWiT 16])
Observation
SL absolute positioning performance may be degraded due to uncertainty in the anchor UEs’ location coordinates and synchronization error (for SL-TDOA) between anchor UEs.
R1-2211507 Summary #2 for SL positioning evaluation Moderator (ZTE)
From Nov 16th session
Observation
For IIOT use case in InF-SH scenario, 9 sources ([Nokia 1], [Huawei 2], [vivo 3], [OPPO 4], [CATT,GOHIGH 5], [ZTE,CMCC 7], [InterDigital 11], [Intel 15], [CEWiT 16]) provide simulation results for FR1, and 1 source ([CEWiT 16]) provides simulation results for FR2.
Observation
For IIOT use case in InF-DH scenario, 7 sources ([Nokia 1], [Huawei 2], [vivo 3], [ZTE,CMCC 7], [InterDigital 11], [Qualcomm 14], [CEWiT 16]) provide simulation results for FR1, and 1 source ([CEWiT 16]) provides simulation results for FR2.
Observation
For Commercial use case, 5 sources ([Huawei 2], [ZTE,CMCC 7], [xiaomi 8], [Qualcomm 14], [Intel 15]) provide simulation results for FR1
R1-2210832 Potential solutions for SL positioning Nokia, Nokia Shanghai Bell
R1-2210837 Potential solutions for sidelink positioning FUTUREWEI
R1-2210901 Remaining issues for SL positioning solutions Huawei, HiSilicon
R1-2211012 Discussion on potential solutions for sidelink positioning vivo
R1-2211203 Further discussion on potential solutions for SL positioning CATT, GOHIGH
R1-2211238 Discussion on potential solutions for SL positioning Spreadtrum Communications
R1-2211268 Discussion on potential solutions for SL positioning LG Electronics
R1-2211302 Discussion on potential solutions for sidelink positioning TOYOTA Info Technology Center
R1-2211369 Discussion on sidelink positioning solutions xiaomi
R1-2211405 Potential solutions for SL positioning Intel Corporation
R1-2211447 Discussion on potential solutions for SL positioning OPPO
R1-2211501 Discussion on potential solutions for SL positioning ZTE
R1-2211530 Discussion on potential solutions for sidelink positioning China Telecom
R1-2211616 Discussion on potential solutions for SL positioning Sony
R1-2211685 Discussion on potential solutions for SL positioning CMCC
R1-2211723 Potential solutions for SL positioning InterDigital, Inc.
R1-2211740 Potential SL Positioning Solutions Lenovo
R1-2211818 On Potential solutions for SL positioning Apple
R1-2211949 Discussion on potential solutions for SL positioning DENSO CORPORATION
R1-2211988 Discussion on potential solutions for SL positioning NTT DOCOMO, INC.
R1-2212050 Discussion on Potential Solutions for SL Positioning Samsung
R1-2212122 Potential Solutions for Sidelink Positioning Qualcomm Incorporated
R1-2212178 Views on potential solutions for SL positioning Sharp
R1-2212192 The potential solutions for sidelink positioning MediaTek Inc.
R1-2212195 Discussion on sidelink positioning ASUSTeK
R1-2212337 Potential solutions for sidelink positioning in NR ITL
R1-2212371 Discussion on potential solutions for SL positioning NEC
R1-2212378 Potential solutions for SL positioning Fraunhofer IIS, Fraunhofer HHI
R1-2212428 Discussion on enhancements for sidelink based positioning CEWiT
R1-2212513 On potential solutions for SL positioning Ericsson
R1-2212661 Moderator Summary #1 on potential solutions for SL positioning Moderator (Qualcomm Incorporated)
From Nov 14th session
Agreement
SL-AoD is included as a potential candidate positioning method, and
· SL-AoD should be deprioritized over the remaining methods that have been recommended to be introduced.
Agreement
With regards to the SL Positioning resource allocation, support
· Alt. 2: either dedicated resource pool(s) and/or a shared resource pool(s) with sidelink communication can be (pre-)configured for SL-PRS.
· Note: this does not imply that the design is the same for both types of resources pools
· Note: shared resources pool(s) should be supported with backward compatibility
R1-2212758 Moderator Summary #2 on potential solutions for SL positioning Moderator (Qualcomm Incorporated)
From Nov 16th session
Agreement
From RAN1 perspective, at least the following 2 operation scenarios are recommended for normative work:
· Operation Scenario 1: PC5-only-based positioning.
· Operation Scenario 2: Combination of Uu- and PC5-based positioning.
Agreement
For Scheme 2, with regards to Resource allocation mechanism for SL-PRS, pick one or both of the following options:
· Option 1: A sensing based resource allocation should be introduced
· Option 2: A random resource selection should be introduced
· In either option 1 or 2, the legacy designs for UE autonomous resource allocation should be used as a starting point. Study if/what enhancements may be needed.
Agreement
With regards to the RTT-type solutions using SL, both single-sided and double-sided RTT methods should be introduced
· Strive to minimize the changes needed on top of the specification support for single-sided RTT, if any, for the introduction of double-sided RTT.
· Note: a UE should be able to support single-sided RTT without having to support double-sided RTT
Agreement
Capture the following TP into the TR 38.859 as a conclusion:
For the solutions for sidelink positioning,
· The following 2 operation scenarios are recommended for normative work
o Operation Scenario 1: PC5-only-based positioning.
o Operation Scenario 2: Combination of Uu- and PC5-based positioning.
· RTT-type solution(s) using SL, SL-AoA and SL-TDOA are recommended for normative work.
o both single-sided and double-sided RTT methods, striving to minimize the changes needed on top of the specification support for single-sided RTT, if any, for the introduction of double-sided RTT
· A new sidelink reference signal (SL-PRS) is recommended for normative work.
o Such a reference signal should use a Comb frequency domain structure and a pseudorandom-based sequence where the existing sequence of DL-PRS should be used as a starting point.
o SCI can be used for reserving/indicating one or more SL-PRS resources
· Both a resource allocation Scheme 1 and Scheme 2 is recommended for normative work, where Scheme 1 corresponds to a network-centric operation SL-PRS resource allocation and Scheme 2 corresponds to UE autonomous SL-PRS resource allocation.
· With regards to the SL-PRS transmission, both dedicated resource pool and shared resource pool with Rel-16/Rel-17/Rel-18 SL communication are recommended for normative work.
o For SL Positioning resource (pre-)configuration in a shared resource pool with Rel-16/17/18 sidelink communication, backward compatibility with legacy Rel-16/17 UEs should be ensured.
· Unicast, Groupcast (not including many to one) and Broadcast of SL-PRS transmission are recommended for normative work.
Agreement
A dedicated SL-PRS resource pool is (pre-)configured in the only SL BWP of a carrier.
R1-2212900 Moderator Summary #3 on potential solutions for SL positioning Moderator (Qualcomm Incorporated)
From Nov 17th session
Agreement
With regards to the power control for SL-PRS at least Open Loop PC should be introduced.
Agreement
For SL-TDOA, DL-TDOA-like operation and UL-TDOA-like operation should be introduced.
· A UE is not required to support both DL-TDOA-like operation and UL-TDOA-like operation
Agreement
With regards to the Positioning methods supported using SL-PRS measurements
o SL-PRS based Rx-Tx measurement
o SL-PRS based RSTD measurement
o SL-PRS based RSRP measurement
o SL-PRS based RSRPP measurement
o SL-PRS based RTOA measurement
o SL-PRS based Azimuth of arrival (AoA) and SL zenith of arrival (ZoA) measurement
R1-2212938 Moderator Summary #4 on potential solutions for SL positioning Moderator (Qualcomm Incorporated)
From Nov 18th session
Agreement
Update the agreed TP into the conclusion section of the TR 38.859 as follows:
For the solutions for sidelink positioning,
· The following 2 operation scenarios are recommended for normative work
o Operation Scenario 1: PC5-only-based positioning.
o Operation Scenario 2: Combination of Uu- and PC5-based positioning.
· RTT-type solution(s) using SL, SL-AoA and SL-TDOA are recommended for normative work.
o both single-sided and double-sided RTT methods, striving to minimize the changes needed on top of the specification support for single-sided RTT, if any, for the introduction of double-sided RTT
o For SL-TDOA, DL-TDOA-like operation and UL-TDOA-like operation is recommended for normative work.
o For the support of the above methods the following measurements are recommended for normative work:
· SL-PRS based Rx-Tx measurement
· SL-PRS based RSTD measurement
· SL-PRS based RSRP measurement
· SL-PRS based RSRPP measurement
· SL-PRS based RTOA measurement
· SL-PRS based Azimuth of arrival (AoA) and SL zenith of arrival (ZoA) measurement
· A new sidelink reference signal (SL-PRS) is recommended for normative work.
o Such a reference signal should use a Comb frequency domain structure and a pseudorandom-based sequence where the existing sequence of DL-PRS should be used as a starting point.
o SCI can be used for reserving/indicating one or more SL-PRS resources
o With regards to the power control for SL-PRS at least Open Loop PC is recommended for normative work.
· Both a resource allocation Scheme 1 and Scheme 2 is recommended for normative work, where Scheme 1 corresponds to a network-centric operation SL-PRS resource allocation and Scheme 2 corresponds to UE autonomous SL-PRS resource allocation.
· For resource allocation mechanism for SL-PRS in Scheme 2, a sensing based resource allocation, or a random resource selection, or both, should be introduced, where the legacy designs for UE autonomous resource allocation are used as a starting point.
· With regards to the SL-PRS transmission, both dedicated resource pool and shared resource pool with Rel-16/Rel-17/Rel-18 SL communication are recommended for normative work.
o For SL Positioning resource (pre-)configuration in a shared resource pool with Rel-16/17/18 sidelink communication, backward compatibility with legacy Rel-16/17 UEs should be ensured.
· Unicast, Groupcast (not including many to one) and Broadcast of SL-PRS transmission are recommended for normative work.
R1-2210902 Remaining issues for RAT-dependent integrity Huawei, HiSilicon
R1-2211013 Discussion on solutions for integrity of RAT-dependent positioning vivo
R1-2211204 Further discussion on solutions for integrity of RAT dependent positioning techniques CATT
R1-2211311 Views on solutions for integrity of RAT-dependent positioning techniques Nokia, Nokia Shanghai Bell
R1-2211434 Discussions on Integrity for NR Positioning OPPO
R1-2211502 Discussion on integrity of RAT dependent positioning ZTE
R1-2211617 On Error Sources for Integrity of NR Positioning Sony
R1-2211686 Discussion on integrity for RAT-dependent positioning CMCC
R1-2211713 Discussions on Integrity for NR RAT-dependent Positioning BUPT
R1-2211726 Discussion on integrity for RAT dependent positioning techniques InterDigital, Inc.
R1-2211742 Integrity aspects for RAT-dependent positioning Lenovo
R1-2211989 Discussion on solutions for integrity of RAT dependent positioning techniques NTT DOCOMO, INC.
R1-2212051 Discussion on Integrity of RAT Dependent Positioning Samsung
R1-2212123 Integrity for RAT dependent positioning Qualcomm Incorporated
R1-2212179 Views on solutions for integrity of RAT dependent positioning techniques Sharp
R1-2212514 Error Sources characterization for integrity of RAT dependent positioning techniques Ericsson
R1-2212551 FL summary #1 on integrity of RAT dependent positioning techniques Moderator (InterDigital)
Presented in Nov 14th session.
R1-2212722 FL summary #2 on integrity of RAT dependent positioning techniques Moderator (InterDigital)
From Nov 16th session
Agreement
Capture the following in TR 38.859 in Clause “6.1.3 Summary of Evaluation Results for Integrity for RAT-Dependent Positioning Techniques”
· The distribution of timing measurement error has been studied with evaluations in the following sources : [R1-2208454, Huawei, HiSilicon], [R1-2208649, vivo], [R1-2208735, Nokia Nokia Shanghai Bell], [R1-2209214, R1-2211502, ZTE], [R1-2209488, InterDigital],[R1-2209737, R1-2212051, Samsung], [R1-2210176, Ericsson].
· The distribution of angle measurement error has been studied with evaluations in the following sources : [R1-2208454, R1-2210902, Huawei, HiSilicon], [R1-2208649, vivo], [R1-2209214, R1-2211502, ZTE], [R1-2210176, Ericsson].
Agreement
Conclusion
For LMF-based positioning integrity mode, for UL-TDOA, inter-TRP synchronization error can be caused in part by errors in SFN initialization time.
Note: Definition of “LMF-based positioning integrity mode” can be found in Table 9.4.1.1.1 in TR 38.857.
Conclusion
· RAN1 could not reach consensus on whether beam information (NR-TRP-BeamAntennaInfo) and boresight direction of DL PRS (NR-DL-PRS-BeamInfo) are error sources or not for DL-AoD for UE-based positioning integrity mode.
Agreement
Capture the following in TR 38.859 in Clause “Annex B.2: Evaluation Results for Integrity for RAT-Dependent Positioning Techniques”.
B.2.1 Results from source [Huawei, HiSilicon]
B.2.1.1 Description of evaluation scenarios
Details related to evaluation scenarios can be found in [1, 17, Huawei, HiSlilicon].
B.2.1.2 Evaluation results related to the distribution of measurement error
Details of the evaluation results related to the distribution of timing measurement error can be found in [17, Huawei, HiSlilicon].
Details of the evaluation results related to the distribution of angle measurement error can be found in [1, 17, Huawei, HiSlilicon].
B.2.2 Results from source [vivo]
B.2.2.1 Description of evaluation scenarios
Details related to evaluation scenarios can be found in [20, vivo].
B.2.2.2 Evaluation results related to the distribution of measurement error
Details of the evaluation results related to the distribution of timing measurement error can be found in [20, vivo].
Details of the evaluation results related to the distribution of angle measurement error can be found in [20, vivo].
B.2.3 Results from source [Nokia, Nokia Shanghai Bell]
B.2.3.1 Description of evaluation scenarios
Details related to evaluation scenarios can be found in [21, Nokia, Nokia Shanghai Bell].
B.2.3.2 Evaluation results related to the distribution of measurement error
Details of the evaluation results related to the distribution of timing measurement error can be found in [21, Nokia, Nokia Shanghai Bell].
B.2.4 Results from source [ZTE]
B.2.4.1 Description of evaluation scenarios
Details related to evaluation scenarios can be found in [6, 26, ZTE].
B.2.4.2 Evaluation results related to the distribution of measurement error
Details of the evaluation results related to the distribution of timing measurement error can be found in [6, 26, ZTE].
Details of the evaluation results related to the distribution of angle measurement error can be found in [6, 26, ZTE]
B.2.5 Results from source [InterDigital]
B.2.5.1 Description of evaluation scenarios
Details related to evaluation scenarios can be found in [30, InterDigital].
B.2.5.2 Evaluation results related to the distribution of measurement error
Details of the evaluation results related to the distribution of timing measurement error can be found in [30, InterDigital].
B.2.6 Results from source [Samsung]
B.2.6.1 Description of evaluation scenarios
Details related to evaluation scenarios can be found in [13, 31, Samsung].
B.2.6.2 Evaluation results related to the distribution of measurement error
Details of the evaluation results related to the distribution of timing measurement error can be found in [13, 31, Samsung].
B.2.7 Results from source [Ericsson]
B.2.7.1 Description of evaluation scenarios
Details related to evaluation scenarios can be found in [35, Ericsson].
B.2.7.2 Evaluation results related to the distribution of measurement error
Details of the evaluation results related to the distribution of timing measurement error can be found in [35, Ericsson].
Details of the evaluation results related to the distribution of angle measurement error can be found in [35, Ericsson].
Agreement
At least DL-PRS RSRPP of the first path or RSRP is an error source for DL-AoD for LMF-based positioning integrity mode.
· Note: RAN1 did not determine the model of the error source
· Note: Definition of “LMF-based positioning integrity mode” can be found in Table 9.4.1.1.1 in TR 38.857
Agreement
· Inter-TRP synchronization error is an error source for UE-assisted DL-TDOA for LMF-based positioning integrity mode
· FFS: Specification impact
· Note: Definition of “LMF-based positioning integrity mode” can be found in Table 9.4.1.1.1 in TR 38.857
Agreement
For LMF-based positioning integrity mode, for DL-TDOA, inter-TRP synchronization error can be caused in part by errors in SFN initialization time.
· Note: Definition of “LMF-based positioning integrity mode” can be found in Table 9.4.1.1.1 in TR 38.857
R1-2212793 FL summary #3 on integrity of RAT dependent positioning techniques Moderator (InterDigital)
From Nov 17th session
Agreement (further modified as below in Nov 18th session)
· For LMF-based positioning integrity mode, for DL-TDOA, DL-AoD, UL-TDOA, UL-AoA and multi-RTT, the following distributions are identified as candidates for modeling the distribution of TRP location (e.g., Geographical Coordinates in TS 38.455) error
o Uniform distribution
o Normal distribution
· Note: it is up to RAN2 how to use the identified distributions
Agreement (further modified as below in Nov 18th session)
· For LMF-based positioning integrity mode, for UL-AoA, the following distributions are identified as candidates for modeling the distribution of ARP location (e.g., ARPLocationInformation in TS 38.455) error
o Uniform distribution
o Normal distribution
· Note: it is up to RAN2 how to use the identified distributions
Final summary in R1-2212933.
R1-2210903 Remaining issues for carrier phase positioning Huawei, HiSilicon
R1-2211014 Discussion on carrier phase measurement enhancements vivo
R1-2211100 High precision positioning of dual frequency carrier phase BUPT
R1-2211205 Further discussion on improved accuracy based on NR carrier phase measurement CATT
R1-2211259 Experiment and Simulation Result on Carrier Phase Based Positioning Locaila
R1-2211312 Views on improved accuracy based on NR carrier phase measurement Nokia, Nokia Shanghai Bell
R1-2211370 Improved accuracy based on NR carrier phase measurement xiaomi
R1-2211406 Improved positioning accuracy with NR carrier phase measurements Intel Corporation
R1-2211435 Discussions on Carrier Phase Measurement for NR Positioning OPPO
R1-2212520 Discussion on carrier phase measurement based positioning ZTE (rev of R1-2211503)
R1-2211687 Discussion on carrier phase positioning CMCC
R1-2211728 Discussion on positioning based on NR carrier phase measurement InterDigital, Inc.
R1-2211743 On NR carrier phase measurements Lenovo
R1-2211924 Discussion on OFDM based carrier phase measurement in NR LG Electronics
R1-2211990 Discussion on improved accuracy based on NR carrier phase measurement NTT DOCOMO, INC.
R1-2212550 Discussion on NR Carrier Phase Measurement Samsung (rev of R1-2212052)
R1-2212124 Phase Measurements in NR Positioning Qualcomm Incorporated
R1-2212193 The potential solutions for carrier phase measurement MediaTek Inc.
R1-2212359 Discussion on NR carrier phase positioning NEC
R1-2212380 NR carrier phase measurements for positioning Fraunhofer IIS, Fraunhofer HHI
R1-2212519 Views on NR carrier phase measurement for positioning accuracy enhancement IIT Kanpur, CEWiT (rev of R1-2212415)
R1-2212515 Improved accuracy based on NR carrier phase measurement Ericsson
R1-2212545 FL Summary #1 for improved accuracy based on NR carrier phase measurements Moderator (CATT)
From Nov 14th session
Agreement
Capture the following TP into TR 38.859 as a conclusion (Section 6.3.3)
Regarding the reference signals for NR carrier phase positioning:
·
Existing DL PRS and UL SRS for positioning purpose are
recommended as the reference signals to enable positioning based on NR carrier
phase measurements for both UE-based and UE-assisted positioning if NR CPP is
introduced.
·
Note: The use of SRS MIMO for NR carrier phase
positioning is transparent for UE
Agreement
Capture the following TP into TR 38.859 as a conclusion.
Regarding the physical layer measurements for NR carrier phase positioning:
· New measurements are recommended to be introduced for supporting UE-based and UE-assisted NR carrier phase positioning, if NR CPP is introduced. The new measurements include, at least, the following:
o For DL carrier phase positioning, the following candidate measurements are identified (potential down-selection may be considered during normative work).
§ the difference between the carrier phase measured from the DL PRS signal(s) of the target TRP and the carrier phase measured from the DL PRS signal(s) of the reference TRP;
§ the carrier phase measured from the DL PRS signal(s) of a TRP.
o For UL carrier phase positioning, the carrier phases measured from the UL SRS for positioning purpose is identified as the UL carrier phase measurements.
· Note: this proposal does not imply which carrier phase measurements are mapped to which positioning technique
Agreement
Capture the following TP into TR 38.859 as a conclusion:
Agreement
Capture the following TP into TR 38.859 as a conclusion:
R1-2212546 FL Summary #2 for improved accuracy based on NR carrier phase measurements Moderator (CATT)
From Nov 16th session
Agreement
Capture the following observation in TR 38.859 (Section 6.3.2):
The accuracy of NR carrier phase positioning is evaluated under different scenarios (e.g., InF-SH, InF-DH) defined in TS 38.901 without considering the error sources listed in Annex X.Y.Z (e.g., timing/ frequency errors, antenna PCO and ARP position errors). The evaluation results can be seen as the reference for studying the impacts of the error sources listed in Annex X.Y.Z . 9 out of 11 sources ([Huawei/R1-2210903][vivo/R12211014][ CATT/R1-2211205][ Nokia/R1-2211312][ZTE/R1-2212520][LGE/ R1- 2211924][ Qualcomm/R1-2212124][Samsung, R1-2212550][Ericsson, R1-2212515]) show that the centimeter-level positioning accuracy can be achieved by the use of carrier phase measurements at least when other error sources are not considered. 2 out of 11 sources ([Intel/R1-2211406][OPPO/R1-2211435[9]) show that the centimeter-level positioning accuracy can be achieved by the use of ideal resolution of integer ambiguity:
· Source [Huawei, R1-2210903] shows (additional results are available in Annex B.4.X[Huawei])
o For InF-SH scenario:
§ (no differential) UL-CPP (Cases 1): <1.0cm @50% and <1.0cm @80%.
§ SD UL-CPP (Case 5): <1.0cm @50% and <1.0cm @80%.
§ DD DL-CPP (Case 9): <1.0cm @50% and <1.0cm @80%.
o For InF-DH scenario
§ (no differential) UL-CPP (Cases 2): <1.0cm @50% and <1.0cm @80%.
§ SD UL-CPP (Case 6): <1.0cm @50% and 0.974m @80%.
§ DD DL-CPP (Case 10): <1.0cm @50% and 1.014m @80%.
· Source [vivo, R1-2211014] shows (additional results are available in Annex B.4.X[vivo])
o For InF-SH scenario:
§ SD DL-CPP (Case 102): <1.0cm@50% and <1.0cm @80%
o For InF-DH scenario
§ SD DL-CPP (Case 202): <1.0cm@50% and 0.33m @80%
· Source [CATT, R1-2211205] shows:
o For InF-SH scenario:
§ SD DL-CPP (Cases 2): <1.0cm @50% and <1.0cm @80%.
§ DD DL-CPP (Cases 3): <1.0cm @50% and <1.0cm @80%.
§ DD DL-CPP (two subcarrier frequencies in one PFL) (Case 4): <1.0cm @50% and <1.0cm @80%.
§ DD DL-CPP (two carrier frequencies, two PFLs) (Case 5): <1.0cm @50% and <1.0cm @80%.
o For InF-DH scenario
§ SD DL-CPP (Cases 7): 0.6cm @50% and 3.0cm @80%.
§ DD DL-CPP (Cases 8): 4.6cm @50% and 14.8cm @80%.
§ DD DL-CPP (two carrier frequencies, two PFLs) (Case 9): 1.0cm @50% and 2.7cm @80%.
· Source [Nokia, R1-2211312] shows:
o For InF-SH scenario:
§ DD DL-CPP (Cases 1): <1cm @50% and <1cm @80%.
· Source [Intel, R1-2211406] shows:
o For InF-SH scenario:
§ SD DL-CPP (Cases 1): <1cm @50% and <1cm @80% (with ideal resolution of integer ambiguity)
· Source [OPPO, R1-2211435] shows:
o For InF-SH scenario:
§ SD DL-CPP (Cases 1): <1cm @50% and <1cm @80% (with ideal resolution of integer ambiguity)
· Source [ZTE, R1-2212520] shows:
o For InF-SH scenario:
§ DL-CPP (multiple subcarriers within one PFL)(Case 4-1-1): 0.11m @ 50% and 0.51m @80%
§ DL-CPP (Case 4-1-2): 0.3cm @ 50% and 0.21m @ 80%
o For InF-DH scenario:
§ DL-CPP (Case 4-2-1):0.33m @50% and 0.66m @ 80%.
· Source [LGE, R1- 2211924] shows:
o For InF-SH scenario (100MHz and 50MHz Bandwidth):
§ SD DL-CPP (horizontal): <1cm @50% and <1cm @80%
§ SD DL-CPP (vertical): <1cm @50% and <1cm @80%
· Source [Qualcomm, R1-2212124] shows:
o For InF-SH scenario (400MHz, FR2)
§ SD DL-CPP(Case 1): 0.002cm @50% and <0.005cm @80%
· Source [Samsung, R1-2212550] shows:
o For InF-SH scenario (10MHz, @3GHz)
§ Round-trip carrier phase with slope: < 1cm @ 50% and <1 cm @ 80%
o For InF-SH scenario (100MHz, @3.5GHz)
§ Time domain and perfect phase : < 1cm @ 50% and <1 cm @ 80%
§ Time domain and estimated phase : < 1cm @ 50% and ~1 cm @ 80%
· Source [Ericsson, R1-2212515] shows:
o For InF-SH scenario
§ DD UL-CPP: <1cm @50% and 2cm @80%
· Note 1: Unless indicated otherwise, the results shown above are for horizontal positioning accuracy with a single carrier of bandwidth of 100MHz in FR1.
· Note 2: Evaluation results above are mainly used as examples. Additional results and more details of the evaluation assumptions may be provided by the sources in Annex B.4-X[Huawei, vivo, CATT, Nokia, Intel, OPPO,ZTE, LGE, Qualcomm, Samsung, Ericsson]).
· Note 3: The evaluation results for legacy positioning approach may also be available in each of the sources, or in TR 38.857.
Agreement
Adopt the following TP modification for TR 38.859 (Section 6.3.2):
==== START of TP for TR 38.859 ====
6.3.2 Summary of Evaluations for NR Carrier Phase Positioning
<Unrelated part omitted>
The impact of the
initial phases of the transmitter and the receiver on NR carrier phase
positioning (CPP) is evaluated in the study item.
The evaluation results from the sources (e.g., [73], [74], [75], [76],
[Nokia/R1-2211312])
show that if the impact of the initial phases of the
transmitter and the receiver are not eliminatedmitigated,
it is impossible to support centimeter-level positioning accuracy.
The effectiveness of using
double differential technique with PRU to eliminate the impact of the initial
phases of the transmitter and the receiver on NR carrier phase positioning are
evaluated in the study item. The evaluation results from the sources ([73], [CATT/R1-221120575],
[ZTE/R1-221252076],
[77], [Nokia/R1-2211312]))
show that the initial phases of the transmitter and the receiver can be removed
effectively by the double differential technique with the use of PRU
:
-
Source [73] shows the
positioning accuracy of <1cm (80%) for InFf-SH
and < 1cm (50%) for InFf-DH
can be reached when the PRU is located within a distance of 5m from the target
UE.
-
Source [75][CATT/R1-2211205]
shows the positioning accuracy of <1cm (80%) for InFf-SH
and 4.6<1cm
(50%) for InFf-DH
can be reached under the under condition that the PRU is
located a fixed location in LOS of the TRP.
- Source [77] shows that the accuracy of <1cm (50%) when the PRU is located within 1m of the target UE. However, the effectiveness reduces when the PRU is located away from the target UE because the channel conditions of the PRU is different from the target UE.
- Source [Nokia/R1-2211312] shows the positioning accuracy of < 1cm (80%) for InF-SH can be reached under the condition that the PRU is located a fixed location as shown in [Nokia/R1-2211312].
- Source [ZTE/R1-2212520] shows the positioning accuracy of < 1cm (50%) for InF-SH can be reached under the condition that the integer ambiguity range N is limited to ±1.
- Source [IIT Kanpur, R1-2212519] shows the distance accuracy degrades from 0.5cm @ 50% and 5.2cm @80% to 3.3cm @50% and 4.8cm @ 80% by the initial phase offset for InF-DH scenario.
- Note 1: in the above results, all other error sources (except initial phase error) were not modelled.
- Note 2: Unless indicated otherwise, the results shown above are for horizontal positioning accuracy with a single carrier of bandwidth of 100MHz in FR1.
- Note 3. Evaluation results above are mainly used as examples. Additional results and more details of the evaluation assumptions may be provided by the sources in Annex B.4-X[Huawei, vivo, CATT, Nokia, ZTE, IIT Kanpur].
==== END of TP ====
Agreement
Adopt the following TP modification for TR 38.859 (Section 6.3.2):
==== START of TP for TR 38.859 ====
6.3.2 Summary of Evaluations for NR Carrier Phase Positioning
<Unrelated part omitted>
The impact of the residual CFO at the transmitter and the receiver for NR carrier phase positioning was evaluated during the study item.
- The evaluation results from the sources ([73], [76]) show that the impact of residual CFO on carrier phase positioning is negligible.
- The evaluation results from the source ([75]) show that the impact of the residual CFO on the performance of carrier phase positioning can be mitigated with the use of the double differential technique with a PRU that is located at a fixed location in LOS of the TRP.
- The evaluation results from the source [vivo/R1-2211014] show that the impact of residual CFO on carrier phase measurement is negligible. However carrier phase positioning accuracy degrades significantly with residual CFO with SD DL-CPP:
o With UE residual CFO 30Hz and TRP residual CFO 10Hz, the accuracy drops from 0.0044m to 0.2m @80% and from 0.0014m to 0.0017m@50% in InF-SH.
o With UE residual CFO 100Hz and TRP residual CFO 10Hz, the accuracy drops from 0.0044m to 0.27m @80% and from 0.0014m to 0.0024m@50% in InF-SH.
- The evaluation results from the source [LGE, R1- 2211924] show that carrier phase positioning accuracy degrades slightly with residual CFO with DD DL-CPP:
o With maximum residual CFO 30Hz between UE and TRP, the accuracy drops from 0.0010m to 0.0018m @50% and from 0.0046m to 0.0208m @80% in InF-SH.
o With maximum residual CFO 100Hz between UE and TRP, the accuracy drops from 0.0010m to 0.0027m @50% and from 0.0046m to 0.0440m @80% in InF-SH.
- The evaluation results from the source [Qualcomm, R1-2212124] show the impact of Doppler in FR1 at 3kmph is small enough that it has negligible impact on the carrier phase positioning accuracy with DD DL-CPP, in the simulated scenario under the agreed modelling for residual CFO.
- Note 1: Unless indicated otherwise, the results shown above are for horizontal positioning accuracy with a single carrier of bandwidth of 100MHz in FR1.
- Note 2. Evaluation results above are mainly used as examples. Additional results and more details of the evaluation assumptions may be provided by the sources in Annex B.4-X [Huawei, vivo, CATT, ZTE, LGE, Qualcomm].
==== END of TP ====
Agreement
Capture the following observation in TR 38.859:
The impact of the ARP errors on NR carrier phase positioning is evaluated. 9 out of 9 sources ([Huawei, R1-2210903][vivo, R1-2211014][ CATT, R1-2211205][ ZTE, R1-2212520][ LGE, R1- 2211924][ Qualcomm, R1-2212124][ Ericsson, R1- R1-2212515] [Samsung R1-2212550]) show that the ARP errors may have significant impact on NR carrier phase positioning accuracy. 3 out of 8 sources ([Huawei, R1-2210903][ CATT, R1-2211205][ZTE, R1-2212520]) show the impact of gNB ARP position errors on multi-frequency carrier phase positioning is much smaller than the impact on single-frequency carrier phase positioning.
· Source [Huawei, R1-2210903] shows:
o When double differential is not used:
§ For InF-SH scenario with 1cm ARP error:
· UL-CPP (Case 23): 1.3368m @50% and 2.121m @80%
§ For InF-DH scenario with 1cm ARP error:
· UL-CPP (Case 24): 1.2329m @ 50% and 1.9317m @80%
o When double differential is used:
§ For InF-SH scenario with 1cm ARP error:
· (PRU 5m) DD UL-CPP (Case 27): <1cm @ 50% and 0.57269m @80%
· (PRU 2m) DD UL-CPP (Case31): <1cm @ 50% and <1cm @80%
§ For InF-DH scenario with 1cm ARP error:
· (PRU 5m) DD UL-CPP (Case 28): 0.75118m @ 50% and 1.3217m @80%
· (PRU 2m) DD UL-CPP (Case 32): 0.56419m@ 50% and 1.1915m @80%
o When multi-frequency carrier phase positioning is used:
§ For InF-SH scenario with 1cm ARP error and random initial phase:
· (PRU 5m) DD UL-CPP (Case 47): 1.252cm @ 50% and 2.765cm @80%
§ For InF-SH scenario with 5cm ARP error and random initial phase:
· (PRU 5m) DD UL-CPP (Case 48): 5.986cm @ 50% and 0.11879m @80%
· Source [vivo, R1-2211014] shows:
o For InF-SH scenario with 1cm ARP error:
§ SD DL-CPP: 0.09m @50% and 0.20m @80%.
o For InF-SH scenario with 5cm ARP error:
§ SD DL-CPP: 0.18m @50%and 0.28m @80%
· Source [CATT, R1-2211205] shows:
o For InF-SH scenario with 1cm ARP error:
§ DD DL-CPP (Cases 11): <1.0cm @50% and 11.2cm @80%.
§ DD DL-CPP (two subcarrier frequencies within one PFL) (Case 12): <1.0cm @50% and 1.79 cm @80%.
§ DD DL-CPP (two carrier frequencies) (Case 13): <1.0cm @50% and 1.3cm @80%.
o For InF-SH scenario with 5cm ARP error:
§ DD DL-CPP (two carrier frequencies, two PFLs) (Case 15): 3.3cm @50% and 5.6cm @80%.
o For InF-DH scenario with 1cm ARP error:
§ DD DL-CPP (two carrier frequencies, two PFLs) (Case 17): 1.5cm @50% and 3.3cm @80%.
· Source [ZTE, R1-2212520] shows:
o For InF-SH scenario with 1cm ARP error:
§ DL-CPP (single carrier, case 3-2-1): 0.24m@50% and 0.44m@80%.
§ DL-CPP (multiple subcarriers within one PFL, case 3-2-4): 0.12m @50% and 0.25m@80%
o For InF-SH scenario with 5cm ARP error:
§ DL-CPP (single carrier, case 3-2-3): 0.28m@50% and 0.44m@80%
§ DL-CPP (multiple subcarriers within one PFL, case 3-2-6): 0.15m@50% and 0.30m@80%
· Source [LGE, R1- 2211924] shows:
o For InF-SH scenario with 1cm ARP error:
§ DD DL-CPP (single carrier): 0.188m (50%), 0.386m (80%)
· Source [Qualcomm, R1-2212124] shows:
o For InF-SH scenario with 1cm ARP error
§ DD DL-CPP(Case 6, FR2): 3.487cm (50%) and 7.907cm (80%) (PRU-UE range R = 1m, more results with other values of R are available in Annex B.4-X-Qualcomm)
§ DD DL-CPP(Case 14, FR1): 0.05m (50%) and 0.18m (80%)
· Source [Ericsson, R1- R1-2212515] shows:
o For InF-SH scenario with 1cm ARP error (average PRU-UE distance = 1m)
§ DD DL-CPP: 1.5cm (50%) and 3.0cm (80%)
o For InF-SH scenario with 5cm ARP error (average PRU-UE distance = 1m)
§ DD DL-CPP: 10cm (50%) and 0.44m (80%)
· Source [Samsung R1-2212550] shows:
o For InF-SH scenario with 2cm ARP error and random initial phase
§ DL-CPP (single carrier, case 08): 1.06m @50% and 1.54m @80%
· Note 1: Unless indicated otherwise, the results shown above are for horizontal positioning accuracy with a single carrier of bandwidth of 100MHz in FR1.
· Note 2. Evaluation results above are mainly used as examples. Additional results and more details of the evaluation assumptions may be provided by the sources in Annex B.4-X [Huawei, vivo, CATT, ZTE, LGE, Qualcomm, Ericsson].
· Note 3: The evaluation of multi-frequency carriers is based on the agreed assumption in Annex A.4 without requiring a UE to simultaneously measure more than one DL PFL.
Agreement
Capture the following observation in TR 38.859:
The impact of the UE/TRP phase center offset (PCO) errors on NR carrier phase positioning is evaluated in the study item. 2 out of 4 sources ([Huawei, R1-2210903][vivo, R1-2211014]) when UE/TRP antenna PCO model of Example 2 is used, the impact of the PCO errors can be significant. 2 out of 4 sources ([CATT, R1-2211205][Qualcomm, R1-2212124]) shows when UE/TRP antenna PCO model of Example1 is used, the impact of the PCO errors can be negligible.
· Source [Huawei, R1-2210903] shows:
o For InF-SH scenario with a=3:
§ SD DL-CPP (Case 37): 0.8469m @50% and 1.3922m @80%.
§ DD DL-CPP (Case 41): < 1cm @50% and <1cm @80%.
o For InF-DH scenario with a=3:
§ SD DL-CPP (Case 38): 0.9192m @50% and 1.4393m @80%.
§ DD DL-CPP (Cases 42): 0.4896m @50% and 1.2148m @80%
· Source [vivo, R1-2211014] shows:
o For InF-SH scenario with SD DL-CPP:
§ PCO model (a=1, w=[-2, +2], dPhi= [0, 5]): <1cm @50% and 0.06m @80%
§ PCO model (a=3, w=[-5, +5], dPhi= [0, 5]): <1cm @50% and 0.06m @80%
§ PCO model (a=3, w=[-5, +5], dPhi= [0, 20]): 0.046m @50% and 0.19m @80%
· Source [CATT, R1-2211205] shows:
o For InF-SH scenario:
§ DD DL-CPP (Cases 20/21): < 1cm @50% and <1cm @80%.
o For InF-DH scenario:
§ DD DL-CPP (Cases 22/23): <=1.3cm @50% and <=2.8cm @80%
· Source [Qualcomm, R1-2212124] shows:
o For InF-SH scenario:
§ DD DL-CPP (Cases 4, FR2):
· PCO model (a=0, w=5: 0.014cm @50% and 0.063cm @80%
· PCO model (a=1, w=5: 0.015cm @50% and 0.076cm @80%
· PCO model (a=3, w=5: 0.014cm @50% and 0.270cm @80%
§ DD DL-CPP (Cases 12, FR2):
· PCO model (a=1, X=5: 0.04m @50% and 0.08m @80%
· PCO model (a=3, X=5: 0.04m @50% and 0.08m @80%
· Note 1: Unless indicated otherwise, the results shown above are for horizontal positioning accuracy with a single carrier of bandwidth of 100MHz in FR1.
· Note 2. Evaluation results above are mainly used as examples. Additional results and more details of the evaluation assumptions may be provided by the sources in Annex B.4-X [Huawei, vivo, CATT, Qualcomm]
Agreement
Adopt the following TP modification for TR 38.859
==== START of TP for TR 38.859 ====
Annex A.3: Evaluation Methodology for NR Carrier Phase Positioning
<Unrelated part omitted>
Table A.3-1: Assumptions for evaluation of NR carrier phase positioning
|
Assumptions |
Value |
|
|
Scenarios |
● Baseline: InF-SH, InF-DH ● Optional: Indoor Open Office, Umi, Highway scenarios ○ Other evaluation scenarios are not precluded ○ Existing Rel-17 DL/UL reference signals for the Uu interface are to be used for the Highway scenario. |
|
|
Frequency errors – Note 1 |
Ideal |
Practical |
|
Initial residual CFO (is the same for one measurement instances [or multiple phase measurement instances]) |
0 (UE/TRP) |
Uniform distribution within: · [-30, +30] Hz (FR1, UE), [-100, +100] Hz (FR1, UE), · [-120, +120] Hz (FR2, UE), [-400, +400] Hz (FR2, UE), · [-10, +10] Hz (for each TRP, FR1), · [-40, +40] Hz (for each TRP, FR2). |
|
Oscillator-drift (is the same for one or multiple phase measurement instances for positioning fix) |
0 (UE/TRP) |
· [-0.02, +0.02] ppm (each TRP) within measurement duration |
|
Antenna reference point (ARP) location error of a TRP |
No ARP error |
A zero-mean, truncated Gaussian distribution with zero mean and standard deviation of T=[1, 5] cm truncated to 2T in each of (x, y, z) direction |
|
Initial phase of a transmitter |
Modelled as a random variable uniformly distributed within [0, 2pi] · The initial phase of a transmitter applies to all subcarriers of the same carrier frequency associated with the transmitter The initial phases of a transmitter for different carriers can be assumed to be independent of each other. |
|
|
Initial phase of a receiver |
Modelled as a random variable uniformly distributed within [0, 2pi] · The initial phase of a receiver applies to all subcarriers of the same carrier frequency associated with the receiver · The initial phases of a receiver for different carriers can be assumed to be independent of each other. |
|
|
UE/TRP antenna phase center offset (PCO) |
dPCO = a * dPhi + w where · a is the scale factor, a=[0, 1, 3] o FFS: other values · dPhi is the direction difference (in degrees): o Example 1, dPhi is the difference between the true and the calculated (or measured) directions between a transmitter (UE/TRP) and a receiver (TRP/UE).
o Example 2: dPhi is the direction difference between one UE to two TRPs, or between one TRP to two UEs. o Note: Example 1 may be more suitable for modelling the PCO of a uncalibrated antenna; while Example 2 may be more suitable for modelling the residual PCO of a calibrated antenna (see [R1-2208206]). · w is 0 or a random variable uniformly distributed within [-2, +2], or [-5, +5], or [-X, +X] degrees. o
· Note: the above model is valid only when absolute value of dPhi < Y degrees o
|
|
|
Time instances for carrier phase measurements |
o Companies should report their assumptions on UE mobility (e.g., speed) |
|
|
Note 1: The Doppler frequency can be determined based on the UE speed in the evaluation assumption. |
||
==== END of TP for TR 38.859 ====
Agreement
Capture the following TP into TR 38.859 as an evaluation observation (for Section 6.3.2):
The potential benefits of using the carrier phases of multiple carriers or multiple subcarriers are evaluated in the study item.
· The evaluation results from the sources (e.g., [Huawei/R1-2210903][CATT/R1-2211205][ZTE/ R1-2212520]) show that the use of the carrier phases of multiple carriers or multiple subcarriers together with double differential technique are beneficial for improving the accuracy of double differential carrier phase positioning.
· The evaluation results from the source [IIT Kanpur/R1-2212519] shows the use of multiple subcarrier technique is beneficial over single carrier.
· The evaluation from the sources [Qualcomm/R1-2212124]) show that combining carrier phase measurements from multiple groups of subcarriers is inferior to coherent processing of all subcarriers to obtain a single more accurate carrier phase measurements.
· One source ([vivo /R1-2211014]) show there is no benefit with the use of the carrier phases of multiple carriers for carrier phase positioning when single differential carrier phase positioning is used.
· The evaluation results from the source [Samsung/R1-2212250] show that the use of the carrier phases of multiple subcarriers together with round trip carrier phase technique is beneficial for improving the accuracy of carrier phase positioning.
· Source [Huawei, R1-2210903] shows:
o When single-frequency carrier phases are used:
§ For InF-SH scenario with 5cm ARP error and random initial phase:
· (PRU within 5m) DD UL-CPP (Case 45): 0.73594m @ 50% and 1.3812m @80%
o When multi-frequency carrier phases are used:
§ For InF-SH scenario with 5cm ARP error and random initial phase:
· (PRU within 5m) DD UL-CPP (Case 48): 5.986cm @ 50% and 0.11879m @80%
· Source [vivo/R1-2211014] shows:
o When multi-frequency carrier phases are used:
§ For InF-SH scenario without other errors,
· SD DL-CPP horizontal accuracy (Cases 703): < 1cm @50% and <1cm @80%.
§ For InF-SH scenario with ARP error
· SD DL-CPP horizontal accuracy (Cases 703): < 1cm @50% and 0.18m @80%
§ For InF-SH scenario with initial phase error
· SD DL-CPP horizontal accuracy (Cases 704): < 0.18m @50% and 0.34m @80%
§ For InF-SH scenario with PCO
· SD DL-CPP horizontal accuracy (Cases 705): < 0.18m @50% and 0.13m @80%
· Source [CATT, R1-2211205[4]) shows:
o For InF-SH scenario with other errors (ARP error, random initial phase, CFO/ Oscillator-drift)
§ DD DL-CPP horizontal accuracy (Cases 27/28): < 1cm @50% and <=2cm @80%.
o For InF-DH scenario:
§ DD DL-CPP horizontal accuracy (Cases 29): 1.6cm @50% and 3.5cm @80%
· Source [ZTE/R1-2212520]) shows
o When multiple subcarriers with in one PFL are used:
§ For InF-SH scenario with other errors (initial phase on both TRP and UE sides)
· DL-CPP accuracy (Case 1-2-9, N is limited to +1): 0.12 m@50% and 0.25m @80%
· Source [Qualcomm, R1-2212124) shows:
o For InF-SH scenario:
§ DD DL-CPP horizontal accuracy (Case 8, FR2): 0.05526m @50% and 1.42119m @80%.
· Source [IIT Kanpur, R1-2212519[20]) shows:
o For InF-DH scenario:
§ Distance accuracy (Case 3): 0.44cm @50% and 0.55cm @80%
· Source [Samsung, R1-2212550] shows:
o For InF-SH scenario (10MHz, @3GHz)
o With multiple sub-carriers and round-trip carrier phase: < 1cm @ 50% and <1 cm @ 80%
· Note 1: Unless indicated otherwise, the results shown above are for horizontal positioning accuracy with a single carrier of bandwidth of 100MHz in FR1.
· Note 2. Evaluation results above are mainly used as examples. Additional results and more details of the evaluation assumptions may be provided by the sources in Annex B.4-X [Huawei, vivo, CATT, ZTE, Qualcomm, IIT Kanpur].
Agreement
Capture the following for TR 38.859 as observation (Section 6.3.2):
The positioning accuracy of Phase-Difference-based AoD positioning has been evaluated.
Source [Qualcomm R1-2212124] shows that a positioning accuracy of 1m (80%) for InF-SH with 20 MHz, is achievable.
Agreement
Adopt the following TP modification for TR 38.859 (Section 6.3.2):
==== START of TP (for TR 38.859) ====
6.3.2 Summary of Evaluations for NR Carrier Phase Positioning
The methodology for the evaluation of NR carrier phase positioning can be found in Annex A.3.
Different evaluation assumptions may be used for the evaluation cases by different sources. Different algorithms and methods may also be used for estimating the carrier phases and determining UE’s location based on the carrier phases. Thus, for the observations of evaluation results presented in this section, it is important to consider the details of the evaluation assumptions as well as the algorithms and methods provided by each source in the references (e.g., in Annex B.4).
==== END of TP ====
Agreement
Capture the following TP into TR 38.859 in section 6.3.1.
==== START of TP ====
· The potential solutions of integer ambiguity resolution for NR carrier phase positioning were investigated in the study item, which include the following:
o Reporting of the carrier phases of more than one frequency from UE/TRP to LMF;
§ Note: frequency refers to frequency of carrier or frequency of subcarrier(s)
o Reporting of the determined integer ambiguity and/or the search range of the integer ambiguity from UE/TRP to LMF;
o Reporting of the carrier phase measurements together with the legacy positioning measurements from UE/TRP to LMF;
o Reporting of the new measurements from UE /TRP to LMF, e.g., based on carrier phase differentials across multiple subcarriers within a carrier;
§ Note: carrier phase differentials across multiple subcarriers within a carrier can be equivalent to time of arrival
o LMF configure the integer ambiguity range between the TRP and target UE (for UE-based NR CPP).
==== END of TP ====
R1-2212547 FL Summary #3 for improved accuracy based on NR carrier phase measurements Moderator (CATT)
From Nov 17th session
Agreement
Adopt the following TP for TR 38.859 (Section 6.3.2):
==== START of TP ====
The effectiveness of using round-trip carrier phase technique to mitigate the impact of the initial phases of the transmitter and the receiver on NR carrier phase positioning is evaluated by source [Samsung/R1-2212859] for InF-SH, which shows the horizontal positioning accuracy of:
· 0.5cm @80% with continuous sub-carrier allocation in 10 MHz BW (i.e. with enhanced PRS),
· 1cm @80% with Comb-4 sub-carrier allocation in 10 MHz BW and no sub-carrier offset change between symbols (i.e. with enhanced PRS), and
· 1.5cm @80% with Comb-4 sub-carrier allocation in 10 MHz BW and with sub-carrier offset change between symbols (i.e. with existing PRS).
Note: The evaluation results assumed phase coherency between the transmit path and the receive path of each device
==== END of TP ====
R1-2212937 FL Summary #4 for improved accuracy based on NR carrier phase measurements Moderator (CATT)
From Nov 18th session
Agreement
Capture the following TP in the Conclusion of TR 38.859.
==== START of TP ====
Based on the study, it is concluded that it is feasible to use existing DL PRS and SRS signals to obtain the carrier phase measurements for achieving a horizontal accuracy of up to a few centimeters at least at 50% under certain conditions, including the PRU(s) being located in LOS with TRP(s), and the locations of the PRU(s) and TRPs known with centimeter-level accuracy, in the agreed evaluation assumptions.
==== END of TP ====
Including discussions on requirements, evaluations, and potential enhancements.
From AI 5
R1-2210804 LS on SRS in multiple cells RAN2, Huawei
R1-2212726 Summary #1 of SRS in multiple cells Moderator (Huawei)
Decision: From Nov 15th session,
Agreement
Reply to RAN2 with regards to the feasibility of SRS in multiple cells as the following
Comeback for draft LS
R1-2212727 Draft Reply LS on SRS in multiple cells Moderator (Huawei)
Decision: From Nov 16th session, the draft LS in R1-2212727 is endorsed. Final LS is approved in R1-2212728.
From AI 5
R1-2210825 LS on LPHAP information delivery to RAN SA2, Huawei
R1-2212723 Summary #1 of LPHAP information delivery to RAN Moderator (Huawei)
Decision: From Nov 15th session,
Agreement
Reply to SA2 with regards to LPHAP information delivery to RAN as the following.
Comeback for draft LS
R1-2212724 Draft Reply LS on LPHAP information delivery to RAN Moderator (Huawei)
Decision: From Nov 16th session, the draft LS in R1-2212724 is endorsed. Final LS is approved in R1-2212725.
R1-2210904 Remaining issues for LPHAP Huawei, HiSilicon
R1-2211015 Discussion on Low Power High Accuracy Positioning vivo
R1-2211055 Discussions and evaluation of LPHAP enhancements FUTUREWEI
R1-2211206 Further discussion on Low Power High Accuracy Positioning CATT
R1-2211239 Discussion on evaluation and solutions for LPHAP Spreadtrum Communications
R1-2211313 Views on LPHAP Nokia, Nokia Shanghai Bell
R1-2211371 Discussion on Low Power High Accuracy Positioning xiaomi
R1-2211407 On Low Power High Accuracy Positioning Intel Corporation
R1-2211436 Discussion on Low Power High Accuracy Positioning OPPO
R1-2211504 Discussion on low power high accuracy positioning ZTE
R1-2211618 Views on Low Power High Accuracy Positioning Sony
R1-2211688 Discussion on low power high accuracy positioning CMCC
R1-2211730 Discussions on Low Power High Accuracy Positioning (LPHAP) techniques InterDigital, Inc.
R1-2211744 LPHAP considerations Lenovo
R1-2211925 Discussion on LPHAP in idle/inactive state LG Electronics
R1-2211991 Discussion on Low Power High Accuracy Positioning NTT DOCOMO, INC.
R1-2212053 Discussion on LPHAP Samsung
R1-2212125 Requirements, Evaluations, Potential Enhancements for Low Power High Accuracy Positioning Qualcomm Incorporated
R1-2212516 Evaluations for Low Power High Accuracy Positioning Ericsson
R1-2212690 Summary #1 for low power high accuracy positioning Moderator (CMCC)
From Nov 15th session
Observation
Capture the following as an observation in TR 38.859 Section 6.4.3:
· Evaluation results of extending DRX cycle are provided by 13 sources ([2/HW,Hisilicon], [3/vivo], [4/CATT], [6/Spreadtrum], [7/Nokia,NSB], [8/xiaomi], [9/Intel], [11/ZTE], [12/Sony], [13/CMCC], [18/Samsung], [19/Qualcomm], [20/Ericsson]) out of 19 sources, the following is observed:
o Results with extended DRX cycle beyond 10.24s provide power saving gains with respect to that with the baseline DRX cycle of 1.28s, and is beneficial towards meeting the battery life requirement as extended DRX cycle beyond 10.24s allows a UE to remain in a deeper sleep state for a longer duration.
o From the evaluations,
§ Power saving gains achieved with extended DRX cycle with respect to baseline DRX cycle 1.28s are provided by 2 sources ([3/vivo], [13/CMCC]):
· In [3/vivo], 87%~90% power saving gains are achieved with DRX cycle of 30.72s with respect to that with the baseline DRX cycle of 1.28s;
· In [13/CMCC], 35.05%~53.70% power saving gains are achieved with DRX cycle of 10.24s with respect to that with the baseline DRX cycle of 1.28s, and 37.56%~57.53% power saving gains are achieved with DRX cycle of 20.48s with respect to that with the baseline DRX cycle of 1.28s;
§ Results on battery life of extended DRX cycle together with ultra-deep sleep state are provided by 13 sources ([2/HW,Hisilicon], [3/vivo], [4/CATT], [6/Spreadtrum], [7/Nokia,NSB], [8/xiaomi], [9/Intel], [11/ZTE], [12/Sony], [13/CMCC], [18/Samsung], [19/Qualcomm], [20/Ericsson]), and the target requirement of 6~12 months is achieved by 12 sources in some cases.
Observation
Capture the following as an observation in TR 38.859 Section 6.4.3:
· Evaluation results of UE (re)entering RRC_CONNECTED state to obtain SRS (re)configuration for UL/DL+UL positioning are provided by 7 sources ([2/HW,Hisilicon], [3/vivo], [4/Futurewei], [9/Intel], [11/ZTE], [13/CMCC], [19/Qualcomm], [20/Ericsson]) out of 19 sources, the following is observed:
o UE (re)entering RRC_CONNECTED state to obtain SRS (re)configuration increases power consumption, and results without SRS (re)configuration procedure provide power saving gains with respect to that with (re)entering RRC_CONNECTED state to obtain SRS (re)configuration.
o From the evaluations,
§ In [2/HW,Hisilicon], 65.2790% of total power is consumed by SRS (re)configuration for UL positioning; UE (re)entering RRC_CONNECTED state to obtain SRS (re)configuration increases the power consumption by 3 times;
§ In [3/vivo], UE (re)entering RRC_CONNECTED state to obtain SRS (re)configuration every 10.24s/20.48s/40.96s increases the power consumption by 8.71%/4.47%/2.23% with DRX cycle of 1.28s and by 13.38%/6.69%/3.34% with DRX cycle of 10.24s;
§ In [4/Futurewei], 23.81%~52.62% of total power is consumed by SRS (re)configuration for UL positioning, and 21.65%~26.54% of total power is consumed by SRS (re)configuration for DL+UL positioning;
§ In [11/ZTE], 11.6%~34.4% of total power is consumed by SRS (re)configuration for UL positioning with ultra-deep sleep state option 1 with additional transition energy 10000, and 46.2%~77.5% of total power is consumed by SRS (re)configuration for UL positioning with ultra-deep sleep state option 2;
§ In [13/CMCC], 11.28%~52.41% of total power is consumed by SRS (re)configuration for UL positioning; Without SRS (re)configuration procedure, 55.07%/20.38%/11.85% power saving gains are achieved for DRX cycle of 1.28s/10.24s/20.48s.
· Evaluation results on battery life assuming no SRS (re)configuration together with ultra-deep sleep state are provided by 11 sources ([2/HW,Hisilicon], [3/vivo], [6/Spreadtrum], [7/Nokia,NSB], [8/xiaomi], [9/Intel], [11/ZTE], [13/CMCC], [18/Samsung], [19/Qualcomm], [20/Ericsson]) out of 19 sources, and the target requirement of 6~12 months is achieved by all 11 sources.
Observation
Capture the following observation in TR 38.859 Section 6.4.3:
· Summary table of results of overall enhancements (Table 8 in Section 3.2.1).
· Evaluation results on the battery life of overall enhancements including at least one or combinations of DRX cycle beyond 10.24s, ultra-deep sleep state, minimized gaps between PRS/SRS/paging/reporting/synchronization, and no SRS (re)configuration procedure, are provided by 13 sources ([2/HW,Hisilicon], [3/vivo], [4/CATT], [6/Spreadtrum], [7/Nokia,NSB], [8/xiaomi], [9/Intel], [11/ZTE],[12/Sony], [13/CMCC], [18/Samsung], [19/Qualcomm], [20/Ericsson]) out of 19 sources.
· For the evaluation with ultra-deep sleep state option 1 with additional transition energy 10000, results are provided by 13 sources ([2/HW,Hisilicon], [3/vivo], [4/CATT], [6/Spreadtrum], [7/Nokia,NSB], [8/xiaomi], [9/Intel], [11/ZTE],[12/Sony], [13/CMCC], [18/Samsung], [19/Qualcomm], [20/Ericsson]) out of 19 sources, and the following is observed:
o For the baseline LPHAP Type A device with battery capacity C2 of 800mAh, the target requirement of 6~12 months is achieved by 1 source ([20/Ericsson]) with baseline implementation factor K = 1, and is achieved by 8 sources ([3/vivo], [4/CATT], [7/Nokia,NSB], [8/xiaomi], [9/Intel], [11/ZTE], [13/CMCC], [19/Qualcomm]) with optional implementation factor K;
o For the optional LPHAP Type B device with battery capacity C2 of 4500mAh, the target requirement of 6~12 months is achieved by 8 sources ([3/vivo], [4/CATT], [7/Nokia,NSB], [8/xiaomi], [9/Intel], [11/ZTE], [13/CMCC], [19/Qualcomm]) with baseline implementation factor K = 1, and is achieved by 6 sources ([3/vivo], [6/Spreadtrum], [7/Nokia,NSB], [11/ZTE], [13/CMCC], [19/Qualcomm]) with optional implementation factor K;
· For the evaluation with ultra-deep sleep state option 1 with additional transition energy 5000, results are provided by 4 sources ([3/vivo], [9/Intel], [11/ZTE], [13/CMCC]) out of 19 sources, and the following is observed:
o For the baseline LPHAP Type A device with battery capacity C2 of 800mAh, the target requirement of 6~12 months is achieved by 2 sources ([3/vivo], [9/Intel]) with baseline implementation factor K = 1, and is achieved by 4 sources ([3/vivo], [9/Intel], [11/ZTE], [13/CMCC]) with optional implementation factor K;
o For the optional LPHAP Type B device with battery capacity C2 of 4500mAh, the target requirement of 6~12 months is achieved by 3 sources ([3/vivo], [11/ZTE], [13/CMCC]) with baseline implementation factor K = 1, and is achieved by 3 sources ([3/vivo], [11/ZTE], [13/CMCC]) with optional implementation factor K;
· For ultra-deep sleep state option 2 (including TDMed with ultra-deep sleep option 1 for power cycles in which paging reception is required), results are provided by 4 sources ([2/HW,Hisilicon], [8/xiaomi], [11/ZTE], [13/CMCC]) out of 19 sources, and the following is observed:
o For the baseline LPHAP Type A device with battery capacity C2 of 800mAh, the target requirement of 6~12 months is achieved by 4 sources ([2/HW,Hisilicon], [8/xiaomi], [11/ZTE], [13/CMCC]) with baseline implementation factor K = 1, and is achieved by 2 sources ([11/ZTE], [13/CMCC]) with optional implementation factor K;
o For the optional LPHAP Type B device with battery capacity C2 of 4500mAh, the target requirement of 6~12 months is achieved by 1 source ([13/CMCC]) with baseline implementation factor K = 1, and is achieved by 1 source ([13/CMCC]) with optional implementation factor K;
Agreement
Updated the previous observation in TR 38.859 Section 6.4.3 (editorial modifications references for the sources can be made when incorporating into the TR):
· For the evaluation on the battery life of the baseline LPHAP Type A device with battery capacity C2 of 800mAh:
o Based on the results provided by all sources, the target requirement of 6~12 months is not achieved by the existing Rel-17 positioning for UEs in RRC_INACTIVE state with baseline implementation factor K = 1 and baseline evaluation assumptions.
o Based on the results provided by all sources, the target requirement of 6~12 months is not achieved by the existing Rel-17 positioning for UEs in RRC_INACTIVE state with optional implementation factor K or optional evaluation assumptions.
o
For UE-assisted DL
positioning, results are provided by 13 14 sources ([34],
[36], [37] [3/vivo],
[38] [7/Nokia, NSB],
[40], [42] [12/Sony],
[43], [44] [8/xiaomi],
[45], [48], [50], [52], [53], [9/Intel])
out of 20 sources, and the following are observed:
§
The target requirement of 6
months is achieved by 0 source, and is not achieved by 13 14 sources
([34],[36], [3/vivo][37], [7/Nokia, NSB][38],[40], [12/Sony][42],[43], [8/xiaomi][44],[45],[48],[50],[52],[53], [9/Intel])
even with the most power efficient case that I-DRX cycle of 10.24s, 1 RS per 1
I-DRX cycle, high SINR, CG-SDT for measurement reporting, and implementation
factor K = 4.
§
The target requirement of
12 months is achieved by 0 source, and is not achieved by 13 14 sources
([34],[36], [3/vivo],[37], [7/Nokia, NSB][38],[40], [12/Sony][42],[43], [8/xiaomi][44],[45],[48],[50],[52],[53], [9/Intel])
even with the most power efficient case that I-DRX cycle of 10.24s, 1 RS per 1
I-DRX cycle, high SINR, CG-SDT for measurement reporting, and implementation
factor K = 4.
o
For UE-based DL
positioning, results are provided by 10 11 sources ([34],
[36], [3/vivo][37],
[7/Nokia, NSB][38],
[40], [43], [8/xiaomi] [44], [45], [50],
[52],[9/Intel])
out of 20 sources, and the following are observed:
§
The target requirement of 6
months is achieved by 0 source, and is not achieved by 10 11 sources
([34],[36], [3/vivo][37], [7/Nokia, NSB][38],[40],[43], [8/xiaomi][44],[45],[50],[52],[9/Intel])
even with the most power efficient case that I-DRX cycle of 10.24s, 1 RS per 1
I-DRX cycle, high SINR, and implementation factor K = 4.
§
The target requirement of
12 months is achieved by 0 source, and is not achieved by 10 11 sources
([34],[36], [3/vivo][37], [7/Nokia.
NSB][38],[40],[43], [8/xiaomi][44],[45],[50],[52],[9/Intel])
even with the most power efficient case that I-DRX cycle of 10.24s, 1 RS per 1
I-DRX cycle, high SINR, and implementation factor K = 4.
o
For UL positioning, results
are provided by 12 13 sources ([34],
[36], [3/vivo][37],
[7/Nokia, NSB][38],
[40], [43], [8/xiaomi][44], [45], [48],
[50], [52], [53], [9/Intel]) out of 20 sources, and
the following are observed:
§
The target requirement of 6
months is achieved by 0 source, and is not achieved by 12 13 sources
([34], [36], [3/vivo][37], [7/Nokia, NSB][38],
[40], [43], [8/xiaomi] [44], [45], [48],
[50], [52], [53], [9/Intel]) even with the most power
efficient case that I-DRX cycle of 10.24s, 1 RS per 1 I-DRX cycle, high SINR,
no SRS (re)configuration, and implementation factor K = 4.
§
The target requirement of
12 months is achieved by 0 source, and is not achieved by 12 13 sources
([34], [36], [3/vivo][37], [7/Nokia, NSB][38],
[40], [43], [8/xiaomi][44], [45], [48],
[50], [52], [53], [9/Intel]) even with the most power
efficient case that I-DRX cycle of 10.24s, 1 RS per 1 I-DRX cycle, high SINR,
no SRS (re)configuration, and implementation factor K = 4.
o For DL+UL positioning, results are provided by 1 source ([52]) out of 20 sources, and the following are observed:
§
The target requirement of 6
months is achieved by 0 source, and is not achieved by 1 source ([52][20])
even with the most power efficient case that I-DRX cycle of 10.24s, 1 RS per 1
I-DRX cycle, high SINR, no SRS (re)configuration, CG-SDT for measurement
reporting, and implementation factor K = 4.
§
The target requirement of
12 months is achieved by 0 source, and is not achieved by 1 source ([52][20])
even with the most power efficient case that I-DRX cycle of 10.24s, 1 RS per 1
I-DRX cycle, high SINR, no SRS (re)configuration, CG-SDT for measurement
reporting, and implementation factor K = 4.
· For the evaluation on the battery life of the optional LPHAP Type B device with battery capacity C2 of 4500mAh:
o Based on the results provided by all sources, the target requirement of 6~12 months is not achieved by the existing Rel-17 positioning for UEs in RRC_INACTIVE state with the baseline implementation factor K=1 and baseline evaluation assumptions.
o
For UE-assisted DL
positioning, results are provided by 8 9 sources ([36], [3/vivo][37], [7/Nokia, NSB] [38],
[12/Sony][42],
[43], [45], [50], [52], [8/xiaomi]) out of 20 sources, and
the following are observed:
§
The target requirement of 6
months is achieved by 4 5 sources ([36], [38],[45],[52], [8/xiaomi],
[10/Sony]) with the implementation factor K = 4 and by 2 4 sources
([43],[50], [3/vivo],
[7/Nokia, NSB]) with the
implementation factor K >= 2, and is not achieved by 6 5 sources
with the implementation factor K < 4 ([36], [37],[38],[42],[45],[52], [8/xiaomi])
and by 2
4 sources ([43],[50], [3/vivo],
[7/Nokia, NSB]) with the
implementation factor K < 2.
§
The target requirement of
12 months is achieved by 3 5 sources
([43],[50],[52], [3/vivo], [7/Nokia. NSB]) with the
case that I-DRX cycle of 10.24s, 1 RS per 1 I-DRX cycle, high SINR, CG-SDT for
reporting and implementation factor K = 4, and is not achieved by 8 9 sources
([36],
[3/vivo][37], [7/Nokia, NSB][38], [10/Sony][42],[43],[45],[50],[52], [8/xiaomi])
with the implementation factor K < 4.
o
For UE-based DL
positioning, results are provided by 7 8 sources ([36], [3/vivo][37],
[7/Nokia, NSB][38],
[43], [45], [50], [52], [8/xiaomi]) out of 20 sources, and
the following are observed:
§
The target requirement of 6
months is achieved by 4 sources ([36], [38],[45],[52], [8/xiaomi])
with the implementation factor K = 4 and by 2 4 sources
([43],[50],
[3/vivo], [7/Nokia, NSB]) with the implementation factor K >= 2
, and is not achieved by 5 4 sources with the
implementation factor K < 4 ([36], [37],[38],[45],[52], [8/xiaomi])
and by 2
4 sources ([43],[50], [3/vivo],
[7/Nokia, NSB]) with the implementation factor K < 2;
§
The target requirement of
12 months is achieved by 3 5 sources
([43],[50],[52], [3/vivo], [7/Nokia, NSB]) with the
case that I-DRX cycle of 10.24s, 1 RS per 1 I-DRX cycle, high SINR, and
implementation factor K = 4, and is not achieved by 7 8 sources
([36],
[3/vivo] [37], [7/Nokia, NSB][38],
[43], [45], [50], [52], [8/xiaomi]) with the implementation
factor K < 4.
o
For UL positioning, results
are provided by 7 8 sources ([36], [3/vivo][37],
[7/Nokia,
NSB][38], [43], [45], [50], [52], [8/xiaomi])
out of 20 sources, and the following are observed:
§
The target requirement of 6
months is achieved by 4 sources ([36], [38],[45],[52], [8/xiaomi])
with the implementation factor K = 4 and by 2 4 sources
([1143],[1850],[3/vivo], [7/Nokia, NSB])
with the implementation factor K >= 2, and is not achieved by 5 4 sources
([36], [37], [38],[45],[52], [8/xiaomi])
with the implementation factor K < 4 and by 2 4 sources
([43],[50],[3/vivo],[7/Nokia,
NSB]) with the implementation factor K < 2;
§
The target requirement of
12 months is achieved by 3 5 sources
([43],[50],[52],[3/vivo],[7/Nokia, NSB]) with the
case that I-DRX cycle of 10.24s, 1 RS per 1 I-DRX cycle, high SINR, no SRS
(re)configuration, and implementation factor K = 4, and is not achieved by 7 8 sources
([36], [3/vivo][37],
[7/Nokia,
NSB][38], [43], [45], [50], [52], [8/xiaomi])
with the implementation factor K < 4.
o For DL+UL positioning, results are provided by 1 source ([52]) out of 20 sources, and the following are observed:
§ The target requirement of 6 months is achieved by 1 source ([52]) with implementation factor K = 4, and is not achieved by 1 source ([52]) with implementation factor K < 4;
§ The target requirement of 12 months is achieved by 1 source ([52]) with the case that I-DRX cycle of 10.24s, 1 RS per 1 I-DRX cycle, high SINR, no SRS (re)configuration, CG-SDT for measurement reporting, and implementation factor K = 4, and is not achieved by 1 source ([52]) with implementation factor K < 4.
o Note: The implementation factor K is a factor related to the reference device in the model to convert the relative power unit to the battery life. Four values are introduced for K with K = 1 as the baseline and K = 0.5, 2, 4 as optional values. The model is captured in the Annex A.4.
o Note: Without otherwise noted, “high SINR” in the observation refers to the evaluation case that no intra-/inter-frequency RRM and single SSB for synchronization purpose is considered.
Conclusion
The conclusion from RAN1#110bis-e on the benefit of extending paging DRX cycle will be captured in the TR.
R1-2212691 Summary #2 for low power high accuracy positioning Moderator (CMCC)
From Nov 16th session
Observation
Capture the following as an observation in TR 38.859 Section 6.4.3:
· Evaluation results of minimized gaps between PRS/SRS/paging/reporting/synchronization are provided by 10 ([2/HW,Hisilicon], [3/vivo], [6/Spreadtrum], [8/xiaomi], [11/ZTE], [12/Sony], [13/CMCC], [18/Samsung], [19/Qualcomm], [20/Ericsson]) sources out of 19 sources, the following is observed:
o Minimizing gaps between PRS/SRS/paging/reporting/synchronization reduces power consumption, and results with minimized gaps between PRS/SRS/paging/reporting/synchronization provide power saving gains with respect to that without minimized gaps.
o From the evaluations,
§ Comparative results with and without optimization of minimized gaps between PRS/SRS/paging/reporting/synchronization are provided by 3 sources ([12/Sony], [13/CMCC], [20/Ericsson]):
· In [12/Sony], 8%~35% and 12.7%~44.5% power saving gains are achieved for DRX cycle 1.28s and 13.2% and 34% power saving gains for DRX cycle 10.24 sec, with minimized gaps between PRS/SRS/paging/reporting/synchronization with sleep states in TR 38.840 and ultra-deep sleep state option 1 with additional transition energy 10000;
· In [13/CMCC], 5.48%~15.59%, 1.05%~3.60%, and 0.54%~1.96% power saving gains are achieved with minimized gaps between PRS/SRS/paging/reporting/synchronization for DRX cycle 1.28s, 10.24s, and 20.48s with sleep states in TR 38.840; 17.14%~33.33% power saving gains are achieved with minimized gaps between PRS/SRS/paging/reporting/synchronization for DRX cycle of 20.48s with ultra-deep sleep option 1.
o
Results on battery life of
assuming minimized gaps between PRS/SRS/paging/reporting/synchronization
together with DRX cycle equal to or larger than 10.24s and ultra-deep sleep
state are provided by 10 sources ([2/HW,Hisilicon], [3/vivo], [6/Spreadtrum], [8/xiaomi],
[9/Intel], [11/ZTE], [12/Sony], [13/CMCC], [18/Samsung], [19/Qualcomm],
[20/Ericsson]), and the target requirement of 6~12 months is achieved by 9
sources.
· Results of paging and/or PEI triggered positioning are further provided by 2 sources ([11/ZTE], [18/Samsung]) based on minimized gaps, which is beneficial to improve battery life as it allows a UE to perform positioning measurement and/or reporting behaviors:
o In [11/ZTE], PEI triggered positioning improves battery life by 0.24~1.64 months, for DRX cycle 10.24s, with multiple ultra-deep sleep state options;
o In [18/Samsung], paging triggered positioning improves battery life by 0.08 (6.02%) ~0.17 (7.98%) months for DL positioning, and by 0.02 (1.71%)~0.05 (1.96%) months for UL positioning; PEI triggered positioning improves battery life by 0.09 (6.77%) ~0.62 (29.11%) months for DL positioning, and by 0.04 (2.90%) ~0.47 (20.61%) months for UL positioning, for DRX cycle 10.24s and 20.48s, and ultra-deep sleep state option 1 with additional transition energy 10000.
· Results on battery life of skipping paging reception are further provided by 1 source ([2/HW, HiSilicon] out of 19 sources, configuring a DRX cycle longer than positioning periodicity (up to 81.92s) or without paging reception can achieve 44.32%~89% power saving gain and is beneficial to improve battery life as it allows a UE to wake up using ultra-deep sleep state option 2 when only performing positioning related operations to achieve the target requirement of LPHAP. When UE wakes up to perform other operations than just positioning related operations, the UE uses ultra-deep sleep state option 1.
·
Results of only using TRS-based synchronization in adjacent
slot to SRS is are further provided by 1 source ([2/HW,HiSilicon]) under
ultra-deep sleep state option 2 without paging
reception, which achieves 23.33% power saving gain and
further improves battery life with respect to that using SSB-based
synchronization for UL positioning.
Observation for TR 38.859 Section 6.4.3:
· Evaluation results of simplified PRS configuration on both battery life and accuracy are provided by 1 source ([11/ZTE]) out of 19 sources, the following is observed:
o In the case of K=1, C2=800, DRX cycle = 10.24s with ultra-deep sleep option 2, 1-symbol PRS can satisfy 6-month battery life but more than 1 symbol PRS cannot.
o The positioning accuracy of 1-symbol PRS and comb size > 12 barely reduces and can meet the accuracy requirement in some cases.
Agreement
· For the conclusion section of the TR:
o For UL and DL+UL positioning for UEs in RRC_INACTIVE state, the enhancements on SRS for positioning in order to avoid frequent RRC connection for SRS (re)configuration is recommended for normative work.
· For the potential specification impact section of the TR:
o For UL and DL+UL positioning for UEs in RRC_INACTIVE state, the details of solutions for enhancements on SRS for positioning to avoid frequent RRC connection for SRS (re)configuration can be further discussed during normative work, which may include but are not limited to one or combinations of the following:
§ SRS for positioning configurations in multiple cells.
· Note: Details including issues such as interference, timing advance, spatial relation information, pathloss reference and common SRS parameters across multiple cells can be further discussed during normative work.
§ Pre-configuration of one or multiple SRS for positioning configurations.
§ SRS for positioning activation/request procedure(s).
R1-2212692 Summary #3 for low power high accuracy positioning Moderator (CMCC)
From Nov 17th session
Agreement
Extending DRX cycle beyond 10.24s was studied and found beneficial towards meeting the battery life requirement for LPHAP, and is recommended for normative work on Rel-18 positioning enhancements from RAN1’s perspective.
· Note: no RAN1 specification impact has been identified
Agreement
From RAN1’s perspective, DL PRS measurement for UEs in RRC_IDLE state is recommended for the normative work.
Proposal
For the conclusion section of the TR:
· Enhancements on simplified DL PRS configuration with 1-symbol PRS can be studied further and if needed, specified during normative phase.
Proposal
For the potential RAN1 specification impact section of the TR:
· For enhancements on simplified DL PRS configuration, the details of solutions can be left for discussion in the normative phase, which may include but are not limited to simplified DL PRS resource pattern (e.g., 1-symbol PRS, comb size > 12)
R1-2212928 Summary #4 for low power high accuracy positioning Moderator (CMCC)
From Nov 18th session
Agreement
For the conclusion section of the TR:
The study of Rel-18 LPHAP focuses on the evaluation of whether the existing Rel-17 positioning techniques for UEs in RRC_INACTIVE state can support the battery life and positioning requirements, and on the analysis of potential enhancements to address any limitations for UEs in RRC_INACTIVE and/or RRC_IDLE states, as outlined in Clause 6.4.
The target use case for LPHAP is studied and confirmed that the use case 6 defined by SA1 as the single representative use case. The performance requirement of LPHAP use case 6 is defined, including horizontal accuracy, positioning interval, and battery life. It is assumed that the target horizontal positioning accuracy requirement on LPHAP of <1m can be achieved by Rel-16/17 positioning techniques with a positioning bandwidth of at least 100MHz. The main objective of the LPHAP evaluations from the perspective of lower layers is on UE power consumption, as outlined in Clause 6.4.1.
The evaluations on the existing Rel-17 positioning techniques for UEs in RRC_INACTIVE state show that the target battery life required by LPHAP use case 6 cannot be satisfied for majority of the evaluation scenarios that are examined. Based on the evaluation, it is concluded that enhancements to meet the target battery life in Rel-18 are necessary.
The following enhancements are recommended for normative work:
· For UL and DL+UL positioning for UEs in RRC_INACTIVE state, the enhancements on SRS for positioning in order to avoid frequent RRC connection for SRS (re)configuration is recommended for normative work.
· Extending DRX cycle beyond 10.24s was studied and found beneficial towards meeting the battery life requirement for LPHAP, and is recommended for normative work on Rel-18 positioning enhancements from physical layer’s perspective.
· From physical layer’s perspective, DL PRS measurement for UEs in RRC_IDLE state is recommended for the normative work.
Including performance evaluation of existing positioning procedures and measurements with RedCap UEs. The result of the evaluation will be used to assess the necessity of enhancements and, if needed, identify enhancements.
R1-2210905 Remaining issues of RedCap positioning Huawei, HiSilicon
R1-2210921 Discussion on Positioning for RedCap UEs Quectel
R1-2211016 Discussion on positioning for RedCap UEs vivo
R1-2211207 Further discussion on positioning for RedCap UEs CATT
R1-2211314 Views on Positioning for RedCap UEs Nokia, Nokia Shanghai Bell
R1-2211408 Enhancements for positioning for RedCap UEs Intel Corporation
R1-2211437 Discussion on Positioning for RedCap Ues OPPO
R1-2211505 Discussion on Positioning for RedCap UE ZTE
R1-2211619 Views on positioning for RedCap UEs Sony
R1-2211689 Discussion on RedCap positioning CMCC
R1-2211732 Discussions on positioning for RedCap UEs InterDigital, Inc.
R1-2211741 Public Safety Personal Protection Equipment (PPE) FirstNet, AT&T, UK Home Office, Erillisverkot, MINISTERE DE L’INTERIEUR, SyncTechno Inc., Softil, Nkom
R1-2211745 Positioning for RedCap devices Lenovo
R1-2211819 On Positioning for RedCap UEs Apple
R1-2211926 Discussion on positioning support for RedCap Ues LG Electronics
R1-2211992 Discussion on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2212054 Discussion on Positioning for RedCap UEs Samsung
R1-2212126 Positioning for Reduced Capabilities UEs Qualcomm Incorporated
R1-2212180 Views on positioning for RedCap UEs Sharp
R1-2212197 The potential solutions for RedCap UEs for positioning MediaTek Inc.
R1-2212368 Discussion on positioning support for RedCap UEs NEC
R1-2212517 Positioning for RedCap Ues Ericsson
R1-2212601 Feature lead summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
From Nov 15th session
Agreement
Update the following observations in the TR
Observation
Regarding the performance for positioning of Redcap UEs using frequency hopping in IIoT scenarios, considering phase offset between hops:
· In FR1, based on the results provided by the following sources,
o if the phase offset between hops in Frequency hopping is compensated, for InF SH the positioning requirement for IIOT use cases can be achieved using frequency hopping with partial overlap for the purpose of phase offset compensation,
§ Sources in R1-2208457 show that UL TDOA can meet the requirements
§ Sources in R1-2208457, R1-2209217, R1-2211016 show that DL TDOA can meet the requirements
§ Sources in R1-2208652, show that the requirement cannot be met, even if the phase is compensated.
o if the phase offset between hops in Frequency hopping is not compensated
§
Sources in R1-2209217
and R1-2211619 show that DL TDOA can meet the requirements if the
random phase offset is set to be equal or
smaller than 0.52*2π.
§ Sources in R1-2211732 show that DL TDOA cannot meet the requirement with the random phase offset distributed from [-π, π].
o
If the phase
offset is ideally compensated
§
Sources in R1-2208652,
show that DL TDOA can meet the requirements
· In FR2, based on the results provided by the following sources,
o R1-2209994 observed that the requirements can be met even if the phase is not compensated
o R1-2209217 observed that PRS frequency hopping can improve positioning performance if the random phase between hops can be adjusted in FR2, InF-SH scenario.
· Note: Sources used different combinations of number of hops, gap size between hops and partial overlap sizes in their evaluations
· Note: Editorial modifications and addition of references for the sources may be added by the rapporteur when capturing the agreement in the TR, including replacing sources by references and providing the number of sources in the main bullet points, and including additional sources and other revisions.
Observation
Regarding the performance for positioning of Redcap UEs using Rx hopping for reception of the DL PRS or Tx hopping for transmission of the UL SRS in IIoT scenarios, considering time gap between hops:
· In FR1 for InF SH, based on the results provided by the following sources,
o For UL-TDOA, source in R1-2210905 shows that the requirement can be met for a gap of 1ms and cannot be met for a gap of 5ms.
o For DL-TDOA, source in R1-2210905 shows that the requirement can be met for a gap of 1ms and cannot be met for a gap of 5ms.
o For DL-TDOA, source in R1-2212743 shows that the requirement can be met for a gap of 1ms and cannot be met for a gap of more than 2ms
o For DL-TDOA, source in R1- 2211016 shows that the requirement can be met for a gap of 4ms
o For DL-TDOA, source in R1- 2212517 shows that the requirement can be met for a gap of 5ms
Observation
Regarding the performance for positioning of Redcap UEs using Rx hopping for reception of the DL PRS or Tx hopping for transmission of the UL SRS in IIoT or commercial scenarios, considering time gap between hops together with UE speed:
· In FR1, for InF SH based on the results provided by the following sources,
o For UL-TDOA, source in R1-2210905 shows that the horizontal accuracy requirement can be met for a gap of 140us for UE speed of up to 120km/h
o For DL-TDOA, source in R1-2211016 shows that the horizontal accuracy requirement can be met for a gap of 2 or 4 ms for UE speed of up to 30km/h, and cannot be met for 60km/h
o For DL-TDOA, source in R1-2212743 shows that the requirement can be met for a gap of 0.1ms for UE speed of up to 150km/h; the horizontal accuracy requirement can be met for a gap of 0.2ms for UE speed of up to 60km/h; the horizontal accuracy requirement can be met for a gap of 0.5ms for UE speed of up to 30km/h; the horizontal accuracy requirement can be met for a gap of 1ms, 2ms, 5ms for UE speed of up to 3km/h.
· In FR1, for UMi, based on the results provided by the following sources,
o For multi-RTT, source in R1-2212126 shows that the requirement for commercial scenarios cannot be met, but performance of frequency hopping with 5 hops and 640 usec switching gap degrades only marginally for speeds of 30 or 60 kmh over 3kmh.
Observation
Regarding the performance for positioning of Redcap UEs using Rx hopping for reception of the DL PRS in IIoT scenarios, considering timing error during the frequency hopping:
· In FR1, for InF SH based on the results provided by the following sources,
o For DL-TDOA, source in R1-2211016 shows the IIOT horizontal accuracy requirement cannot be met if the timing error is 3ns
o For DL-TDOA, source in R1-2212743 shows the IIOT horizontal accuracy requirement can be met if the timing error is 2ns, but cannot be met if the timing error is 3ns
Observation
In FR1, for InF-SH, the performance of carrier phase positioning with RedCap UEs using 20MHz of bandwidth was evaluated without modeling the agreed error sources
· Sources in [R1-2211016] [R1-2211207] show that a redcap UE using CPP can meet the IIOT requirement under ideal conditions and known integer ambiguity.
· Source in [R1-2212743] shows that a redcap UE using CPP cannot meet the IIOT requirements with a fixed search range of integer ambiguity.
· Source in [R1-2211016] shows that with an estimated integer ambiguity, a redcap UE using CPP cannot meet the IIOT requirements
· Source in [R1-2212054] shows that a redcap UE using CPP can meet the IIOT requirements, under some conditions for integer ambiguity resolution.
· Source in [R1-2212517] shows that a redcap UE using CPP can meet the IIOT requirements if frequency hopping enhancements are also used and cannot meet the IIOT requirements without enhancements.
· Source in [R1-2212126] shows that a redcap UE using phase-difference AoD improves performance over RSRPP-based AoD but cannot meet the IIoT requirements.
R1-2212602 Feature lead summary #2 for Positioning for RedCap UEs Moderator (Ericsson)
R1-2212603 Feature lead summary #3 for Positioning for RedCap UEs Moderator (Ericsson)
From Nov 17th session
Agreement
Capture the following in the TR conclusions:
Agreement
The observation for baseline performance for positioning of RedCap UEs for IIOT scenarios is updated as follow:
Observation
Capture the following observations in the TR, regarding the baseline performance for positioning of Redcap UEs for IIOT scenarios:
· Based on the results provided by a majority of X sources, for InF-SH in FR1, the horizontal positioning requirement for IIOT use cases is not achieved by Rel.17 solutions using 5MHz or 20MHz of bandwidth.
o Sources in R1-2208457, R1-2210179 show that UL TDOA cannot meet the requirement
o Sources in R1-2209994, R1-2210179 show that multi-RTT cannot meet the requirement
o Sources in R1-2208803, R1-2208985, R1-2209061, R1-2209108, R1-2209153, R1-2209217, R1-2209491, R1-2209740, R1-2210179, R1-2212054 show that DL-TDOA cannot meet the requirement
o Source in R1-2208652 shows that the requirement can be met using 20MHz of bandwidth.
o Source in R1-2208652 shows that the requirement cannot be met using 5MHz of bandwidth.
o Source in R1-2211926 shows that UL-AoA cannot meet the requirement
o Source in R1-2212126 shows that DL-AoD cannot meet the requirement
· Based on the results provided by a majority of X sources, for InF-SH in FR2, the horizontal positioning requirement for IIOT use cases is achieved by Rel.17 solutions using 100MHz of bandwidth.
o Sources in R1-2209994 show that multi-RTT can meet the requirement
o Sources in R1-2209217 show that DL-TDOA can meet the requirement
· Based on the result provided by the following source, for InF-DH in FR1, the horizontal positioning requirement for IIOT use cases is not achieved by Rel.17 solutions using 20MHz of bandwidth.
o Source in R1-2209108, R1-2211437, R1-2212743 show that the requirements for IIOT use cases cannot be met for InF-DH.
Agreement
The observation for baseline performance for positioning of RedCap UEs for commercial scenarios is updated as follow:
Observation
· Based on the results provided by R1-2208457 and R1-2211016, for Umi in FR1, the horizontal positioning requirement for commercial use cases is not achieved by Rel.17 solutions using 5MHz or 20MHz of bandwidth and UL-TDOA.
·
Based on the results
provided by R1-2209740 and, R1-2211016, R1-2212743 and R1-2212054, for Umi in FR1, the horizontal positioning requirement for
commercial use cases is not achieved by Rel.17 solutions using 5MHz or 20MHz of bandwidth and DL-TDOA.
· Based on the results provided by R1-2209994 and R1-2211016, for Umi in FR1, the horizontal positioning requirement for commercial use cases is not achieved by Rel.17 solutions using 20MHz or 5 MHz of bandwidth and multi-RTT.
R1-2212949 Feature lead summary #4 for Positioning for RedCap Ues Moderator (Ericsson)
From Nov 18th session
Agreement
Capture the following in section 6.5.3 of the TR:
The following has been identified for potential specification impact of NR positioning for RedCap UEs:
Please refer to RP-223549 for detailed scope of the WI.
R1-2302065 Session notes for 9.5 (Study on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
[112-R18-Pos] – Debdeep (Intel)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2301218 Work Plan for Rel-18 WI on Expanded and Improved NR Positioning Intel Corporation
From AI 5
R1-2301915 LS on PRU procedures SA2, Qualcomm
R1-2302047 Discussion of SA2 LS on PRU Procedures Moderator (Qualcomm Incorporated)
From Wednesday session
Conclusion
Current RAN1 specifications do not support a mechanism to ensure simultaneous measurements/transmissions (e.g. in the same slot(s)) for multiple UEs, including a target UE and a PRU.
Conclusion
A PRU can report its location and associated uncertainty as is the case for other UEs. It is not necessary to always include the PRU location information with the PRU measurements in the same report. The PRU location information and measurements should be decoupled, where decoupled means that the PRU location information is determined independently of the reported measurements, even if the PRU location information and the PRU measurements would be included in the same report.
R1-2302106 Discussion (2nd round) of SA2 LS on PRU Procedures Moderator (Qualcomm)
From Thursday session
Agreement
RAN1 will continue discussions on what enhancements to LPP, NRPPa, and/or RAN signaling are necessary to support simultaneous measurements of the same DL-PRS for multiple UEs, including a target UE and a PRU; and to support simultaneous transmission of SRS for multiple UEs, including a target UE and a PRU.
RAN1 will include the outcome in an LS to SA2 and RAN2, and cc RAN3.
Note: Enhancements might or might not have RAN1 specification impact.
Comeback for draft LS
R1-2302145 [Draft] LS Reply on PRU Procedures Moderator (Qualcomm)
Decision: The draft LS reply in R1-2302145 is endorsed. Final LS is approved in R1-2302146.
Comment is made that extra discussion w.r.t the SA2 LS might be needed in next meeting.
R1-2302220 RAN1 agreements for Rel-18 WI on Expanded and Improved NR Positioning Rapporteur (Intel Corporation)
Including procedures related to transmit power control
R1-2300040 Design of SL positioning reference signal SL-PRS Nokia, Nokia Shanghai Bell
R1-2300063 Discussion on SL positioning reference signal FUTUREWEI
R1-2300079 Considerations on SL-PRS design Huawei, HiSilicon
R1-2300222 Discussion on SL positioning reference signal Spreadtrum Communications
R1-2300301 Discussion on SL positioning reference signal OPPO
R1-2300457 Discussion on SL positioning reference signal vivo
R1-2300580 Discussion on Sidelink positioning reference signal xiaomi
R1-2300684 Discussion on SL positioning reference signal CATT, GOHIGH
R1-2300720 Discussion on SL positioning reference signal China Telecom
R1-2300787 SL positioning reference signal Sharp
R1-2300802 Discussion on SL positioning reference signal ZTE
R1-2300836 Discussion on SL positioning reference signal NEC
R1-2300879 Considerations on SL Positioning Reference Signal Sony
R1-2300898 Discussion on Sidelink Positioning Reference Signal Panasonic
R1-2300952 On SL Positioning Reference Signals Intel Corporation
R1-2301006 Discussion on SL positioning reference signal CMCC
R1-2301116 SL-PRS design and power control for SL-PRS InterDigital, Inc.
R1-2301142 Design considerations on SL positioning reference signal Fraunhofer IIS, Fraunhofer HHI
R1-2301211 Discussion on SL PRS Aspects Lenovo
R1-2301268 On SL Positioning Reference Signal Samsung
R1-2301300 Discussion on sidelink positioning reference signal ASUSTeK
R1-2301350 Discussion on SL positioning reference signal Apple
R1-2301417 Reference Signal Design for SL Positioning Qualcomm Incorporated
R1-2301497 Discussion on reference signal for SL positioning NTT DOCOMO, INC.
R1-2301536 Discussion on SL positioning reference signal LG Electronics
R1-2301636 Reference signal design for sidelink positioning MediaTek Inc.
R1-2301678 SL positioning reference signal design Ericsson
R1-2301695 View on SL positioning reference signal design CEWiT, Reliance Jio
R1-2301875 FL summary #1 on SL positioning reference signal Moderator (Intel Corporation)
From Tuesday session
Agreement
SL PRS sequence is generated based on Gold sequence:
where c(i) is a pseudo-random sequence as defined in Clause 5.2.1 of TS 38.211.
Agreement
·
For SL PRS sequence
generation, the pseudo-random sequence c(i) initialization equation is defined
as a function of at least: slot number, symbol number, and a parameter 
.
· The pseudo-random sequence c(i) initialization equation is based on initialization equation as for DL PRS
Agreement
For SL PRS sequence
generation, consider at least the following options to define the parameter , and select one option:
·
Option 1: is a higher layer
configured parameter
·
Option 2: is based on 12
bits CRC of PSCCH associated with the SL PRS transmission
· Option 3: based on a combination of higher layer configured parameter from a configured ID list and 12 bits of CRC of PSCCH associated with the SL PRS transmission
·
Option 5: is based on 12bits
LSB of destination ID
·
Option 6: is based on 8 bits
of source ID + 4 zero bits
·
Option 7: is based on the
CRC field of the 2nd SCI associated with SL PRS transmission, if there is a 2nd
SCI defined.
Agreement
Range of the parameter is: 
.
Agreement
A SL PFL is not defined. SL positioning RS are defined directly with respect to and contained within a single SL BWP and carrier.
Agreement
Support SCS values for SL PRS include:
R1-2301876 FL summary #2 on SL positioning reference signal Moderator (Intel Corporation)
From Wednesday session
Agreement
For RE-offset sequence for SL PRS, the RE-offset sequences specified for DL PRS are considered as a starting point.
o FFS: Exact RE-offset sequences
Agreement
R1-2302095 FL summary #3 on SL positioning reference signal Moderator (Intel Corporation)
From Thursday session
Agreement
For SL PRS in shared or dedicated resource pools,
Agreement
For SL PRS in shared and dedicated resource pools,
Agreement
TDM-based multiplexing of SL PRS from different UEs in a slot is supported at least for dedicated resource pools.
R1-2302096 FL summary #4 on SL positioning reference signal Moderator (Intel Corporation)
From Friday session
Agreement
The OLPC framework defined for PSSCH/PSCCH is considered as a starting point for OLPC for SL PRS.
R1-2300041 On measurements and reporting for SL positioning Nokia, Nokia Shanghai Bell
R1-2300067 Discussion on measurements and reporting for SL positioning FUTUREWEI
R1-2300080 SL positioning methods, measurements, and reporting Huawei, HiSilicon
R1-2300223 Discussion on measurements and reporting for SL positioning Spreadtrum Communications
R1-2300302 Discussion on measurements and reporting for SL positioning OPPO
R1-2300382 Discussion on measurements and reporting for SL positioning TOYOTA Info Technology Center
R1-2300458 Discussion on measurements and reporting for SL positioning vivo
R1-2300581 Discussion on measurements and reporting for SL positioning xiaomi
R1-2300685 Discussion on measurements and reporting for SL positioning CATT, GOHIGH
R1-2300760 Proposed RTT measurement method using Carrier Phase Positioning Locaila
R1-2300788 Measurements and reporting for SL positioning Sharp
R1-2300803 Discussion on SL positioning measurements and reporting ZTE
R1-2300880 Considerations on SL Positioning Measurements and Reporting Sony
R1-2300953 Measurements and reporting for SL positioning Intel Corporation
R1-2301007 Discussion on measurements and reporting for SL positioning CMCC
R1-2301117 Measurement and reporting for SL positioning InterDigital, Inc.
R1-2301143 Measurements and reporting for SL positioning Fraunhofer IIS, Fraunhofer HHI
R1-2301212 Discussion on SL Positioning Measurement and Reporting Lenovo
R1-2301269 On Measurements and Reporting for SL Positioning Samsung
R1-2301351 On Measurements and reporting for SL positioning Apple
R1-2301418 Measurements and Reporting for SL Positioning Qualcomm Incorporated
R1-2301498 Discussion on measurement and reporting for SL positioning NTT DOCOMO, INC.
R1-2301537 Discussion on measurements and reporting for SL positioning LG Electronics
R1-2301562 Discussion on measurements and reporting for SL positioning DENSO CORPORATION
R1-2301633 Measurement and reporting design for sidelink positioning MediaTek Inc.
R1-2301679 Measurements and reporting for SL positioning Ericsson
R1-2301696 View on SL positioning methods, measurements and reporting for SL positioning CEWiT, Reliance Jio
R1-2301950 Summary #1 on Measurements and reporting for SL positioning Moderator (vivo)
From Tuesday session
Agreement
SL PRS reference signal received power (SL PRS-RSRP)
With regard to the reference point
Agreement
SL PRS reference signal received path power (SL PRS-RSRPP),
With regard to the reference point
Agreement
SL-PRS based RTOA TSL-RTOA is
defined as the beginning time of SL subframe #i containing SL-PRS received from
a UE, relative to the RTOA Reference Time. The SL RTOA
reference time is defined as 
, where
Agreement
Support both GCS and LCS for SL-PRS based Azimuth of arrival (AoA) and zenith of arrival (ZoA) measurement.
R1-2301951 Summary #2 on Measurements and reporting for SL positioning Moderator (vivo)
From Wednesday session
Agreement
For definition of SL-PRS based Rx-Tx measurement, downselect one of the following alternatives in RAN1# 112b to minimize the impact of UE reference timing offset and mobility
Agreement
Study measurement report content for both the cases of sidelink positioning measurement reported to LMF and UE.
Agreement
For SL-PRS based Rx-Tx measurement for double sided RTT, consider sidelink PRS transmission without order restriction between multiple rounds of PRS transmission of involved UEs.
· FFS on how to differentiate different PRS transmissions for sidelink PRS Rx-Tx measurement and report
· FFS on impact of Scheme 2 resource allocation when the different orders in double sided RTT is considered and whether and how to minimize number of different orders
o Aspects related to scheme 2 resource allocation are to be discussed in agenda 9.5.1.3
R1-2301952 Summary #3 on Measurements and reporting for SL positioning Moderator (vivo)
From Thursday session
Agreement
Study the necessity and scenarios of including location information and quality information of the location of a UE in sidelink positioning measurement report, considering different measurements and different reporting targets (LMF and UE).
Agreement
Study the following candidates for identification information in sidelink positioning report, considering different measurements and different reporting targets (LMF and UE):
Agreement
LoS/NLoS indicator can be included in a sidelink positioning measurement report, considering different reporting targets (LMF and UE).
Agreement
Companies are encouraged to provide expected measurement report content in the following table to facilitate discussion in RAN1 #112bis-e.
Note: this does not imply a different measurement report content for reporting to LMF or to UE.
Table 6.2 Collection of measurement report content
|
|
reporting to LMF |
reporting to UE |
|
SL-PRS based Rx-Tx measurement |
|
|
|
SL-PRS based RSTD measurement |
|
|
|
SL-PRS based RSRP measurement |
|
|
|
SL-PRS based RSRPP measurement |
|
|
|
SL-PRS based RTOA measurement |
|
|
|
SL-PRS based Azimuth of arrival (AoA) and SL zenith of arrival (ZoA) measurement |
|
|
|
etc |
|
|
Including details related to the support of unicast/groupcast/broadcast of SL PRS transmissions.
R1-2300042 On resource allocation for SL positioning reference signal Nokia, Nokia Shanghai Bell
R1-2300068 Discussion on resource allocation for SL PRS FUTUREWEI
R1-2300081 Resource allocations for SL positioning Huawei, HiSilicon
R1-2300224 Discussion on resource allocation for SL positioning reference signal Spreadtrum Communications
R1-2300303 Discussion on resource allocation for SL positioning reference signal OPPO
R1-2300383 Discussion on resource allocation for SL positioning TOYOTA Info Technology Center
R1-2300459 Discussion on resource allocation for SL positioning reference signal vivo
R1-2300582 Discussion on resource allocation for SL positioning reference signal xiaomi
R1-2300686 Discussion on Resource allocation for SL positioning reference signal CATT, GOHIGH
R1-2300721 Discussion on resource allocation for SL positioning reference signal China Telecom
R1-2300804 Discussion on resource allocation for SL positioning reference signal ZTE
R1-2300837 Discussion on resource allocation for SL positioning reference signal NEC
R1-2300881 Considerations on SL Positioning Reference Signal Resource allocation Sony
R1-2300954 On resource allocation for SL positioning Intel Corporation
R1-2301008 Discussion on resource allocation for SL positioning reference signal CMCC
R1-2301118 Resource allocation for SL positioning reference signal InterDigital, Inc.
R1-2301144 Considerations on SL-PRS resource allocation Fraunhofer IIS, Fraunhofer HHI
R1-2301213 Discussion on SL Positioning Resource Allocation Lenovo
R1-2301270 On Resource Allocation for SL Positioning Reference Signal Samsung
R1-2301302 Discussion on resource allocation for SL PRS ASUSTeK
R1-2301352 On Resource allocation for SL positioning reference signal Apple
R1-2301841 Resource Allocation for SL-PRS Qualcomm Incorporated (rev of R1-2301419)
R1-2301499 Discussion on resource allocation for SL positioning NTT DOCOMO, INC.
R1-2301538 Discussion on resource allocation for SL positioning reference signal LG Electronics
R1-2301547 Resource allocation for SL positioning reference signal Sharp
R1-2301561 Discussion on resource allocation for SL positioning reference signal DENSO CORPORATION
R1-2301634 Resource allocation for SL-PRS MediaTek Inc.
R1-2301649 Considerations on resource allocation for SL positioning reference signal ITL
R1-2301680 Resource allocation for SL positioning reference signal Ericsson
R1-2301697 View on SL positioning resource allocation for SL positioning reference signal CEWiT, Reliance Jio
R1-2302004 Moderator Summary #1 on resource allocation for SL PRS Moderator (Qualcomm)
From Tuesday session
Agreement
· A UE can be configured to perform either resource allocation Scheme 1 or Scheme 2, applicable to all resource pools (dedicated or shared resource pools).
· SL PRS unicast/groupcast/broadcast can occur in either a shared or a dedicated resource pool.
R1-2302045 Moderator Summary #2 on resource allocation for SL PRS Moderator (Qualcomm)
From Wednesday session
Agreement
For a dedicated resource pool for positioning:
Agreement
For a dedicated resource pool for Positioning,
R1-2302094 Moderator Summary #3 on resource allocation for SL PRS Moderator (Qualcomm)
From Thursday session
Agreement
Regarding Scheme 1 SL-PRS resource allocation, do not further consider a transmitting UE to receive the SL-PRS resource allocation through higher layers from the LMF (i.e. Option 1 is not pursued further).
Agreement
Sensing based or random selection in Scheme 2 is allowed by (pre-)configured per resource pool (similar to Rel-17 NR sidelink communication).
Agreement
With regards to random resource selection, reuse existing Rel-17 random selection mechanism from sidelink communications.
· Study if any changes are needed
Agreement
In Scheme 2, with regards to the triggering of SL-PRS, support one or both of the following options:
R1-2302162 Moderator Summary #4 on resource allocation for SL PRS Moderator (Qualcomm)
From Friday session
Agreement
For SL-PRS transmission, at least support the following
Agreement
For the scheme 2 sensing-based resource allocation,
R1-2300085 Discussion on carrier phase measurement Huawei, HiSilicon
R1-2300225 Discussion on NR DL and UL carrier phase positioning Spreadtrum Communications
R1-2300307 Discussions on NR carrier phase positioning OPPO
R1-2300460 Discussion on carrier phase positioning vivo
R1-2300538 Discussions on Carrier Phase Measurement for NR Positioning BUPT
R1-2300583 NR DL and UL carrier phase positioning xiaomi
R1-2300687 Discussion on NR DL and UL carrier phase positioning CATT
R1-2300761 Proposed solution for uplink and downlink carrier phase positioning Locaila
R1-2300778 Views on NR DL and UL carrier phase positioning Nokia, Nokia Shanghai Bell
R1-2300805 Discussion on carrier phase measurement based positioning ZTE
R1-2300955 On DL and UL carrier phase positioning Intel Corporation
R1-2301009 Discussion on DL/UL carrier phase positioning CMCC
R1-2301066 Discussion on carrier phase positioning in NR LG Electronics
R1-2301119 Discussion on positioning based on NR carrier phase measurement InterDigital, Inc.
R1-2301214 DL & UL Carrier Phase Positioning Discussion Lenovo
R1-2301271 On NR DL and UL Carrier Phase Positioning Samsung
R1-2301353 On NR DL and UL carrier phase positioning Apple
R1-2301420 NR Carrier Phase Positioning Qualcomm Incorporated
R1-2301500 Discussion on NR DL and UL carrier phase positioning NTT DOCOMO, INC.
R1-2301630 Solutions for carrier phase positioning MediaTek Inc.
R1-2301681 NR DL and UL carrier phase positioning Ericsson
R1-2301724 Discussion on NR UL and DL carrier phase positioning IIT Kanpur, CEWiT
R1-2301828 FL Summary #1 for NR DL and UL carrier phase positioning Moderator (CATT)
From Tuesday session
Agreement
To enable UE-based and UE-assisted NR carrier phase positioning (CPP), one or both of the following new measurements should be introduced:
To enable NG-RAN node-assisted NR carrier phase positioning (CPP), the following new measurement should be introduced:
R1-2301829 FL Summary #2 for NR DL and UL carrier phase positioning Moderator (CATT)
From Wednesday session
Agreement
NR DL reference signal carrier phase (RSCP) (of i-th path) is defined as the phase of the channel response at the i-th path delay derived from the resource elements (REs) that carry the DL PRS signals configured for the measurement. A RSCP is associated with a specific RF frequency.
Agreement
For NR DL reference signal carrier phase difference (RSCPD) measurement for NR CPP, the RSCPD is defined as the difference of RSCPs measured from the DL PRS signals from target TRP and reference TRP.
Agreement
For NR carrier phase positioning, at least support the following approach: enable a UE/TRP to report carrier phase measurements together with the legacy positioning measurements to LMF
R1-2301830 FL Summary #3 for NR DL and UL carrier phase positioning Moderator (CATT)
From Friday session
Agreement
NR UL reference signal carrier phase (RSCP) (of i-th path) is defined as the phase of the channel response at the i-th path delay derived from the resource elements (REs) that carry the UL SRS signal for positioning purpose configured for the measurement. A UL RSCP is associated with a specific RF frequency.
Agreement
To support NR carrier phase positioning, further consider the following options:
Agreement
Rel-17 LOS/NLOS indication (when indicated) applies for the carrier phase measurement(s) in the same report.
From AI 5
R1-2301914 LS on the requirement on low power or high accuracy positioning SA2, Huawei
R1-2301990 Discussion on LS reply regarding LPHAP Moderator (Huawei)
R1-2301991 Draft LS reply on the requirement for LPHAP Moderator (Huawei)
Wednesday session decision: The draft LS in R1-2301991 is endorsed. Final LS is approved in R1-2302074.
R1-2300064 Discussions of LPHAP enhancements FUTUREWEI
R1-2300082 Physical layer aspects of LPHAP Huawei, HiSilicon
R1-2300226 Discussion on LPHAP (Low Power High Accuracy Positioning) Spreadtrum Communications
R1-2300309 Discussion on low power high accuracy positioning OPPO
R1-2300461 Discussion on low power high accuracy positioning vivo
R1-2300584 Discussion on Low Power High Accuracy Positioning xiaomi
R1-2300688 Discussion on Low Power High Accuracy Positioning CATT
R1-2300777 Views on LPHAP Nokia, Nokia Shanghai Bell
R1-2300806 Discussion on low power high accuracy positioning ZTE
R1-2300832 Discussion on Low Power High Accuracy Positioning NEC
R1-2300882 Considerations on Low Power High Accuracy Positioning Sony
R1-2300956 On support of LPHAP Intel Corporation
R1-2301010 Discussion on low power high accuracy positioning CMCC
R1-2301067 Discussion on LPHAP in idle/inactive state LG Electronics
R1-2301141 Discussions on Low Power High Accuracy Positioning (LPHAP) techniques InterDigital, Inc.
R1-2301272 On Low Power High Accuracy Positioning Samsung
R1-2301354 On Low Power High Accuracy Positioning Apple
R1-2301421 Discussion on LPHAP Positioning Qualcomm Incorporated
R1-2301501 Discussion on Low Power High Accuracy Positioning NTT DOCOMO, INC.
R1-2301682 On Low Power High Accuracy Positioning Ericsson
R1-2301967 Summary #1 for low power high accuracy positioning Moderator (CMCC)
From Tuesday session
Agreement
For SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state, support the following:
· An SRS positioning validity area consists of cells configured in the same band and the same carrier, and the following parameters with respect to BWP information of SRS for positioning configuration are commonly applied across cells within the validity area:
Agreement
For SRS for positioning configuration in multiple cells for a UE in RRC_INACTIVE state, at least the following parameters in SRS for positioning configuration are commonly configured across cells within the validity area:
· srs-PosConfig
Agreement
From RAN1 perspective, it is feasible to configure SRS positioning validity area-specific TA timer (e.g., with larger values) for a UE in RRC_INACTIVE state. Details can be up to RAN2.
· For TA validation, use of area-specific RSRP change threshold is feasible
R1-2301968 Summary #2 for low power high accuracy positioning Moderator (CMCC)
From Wednesday session
Agreement
For the determination of UL timing to transmit SRS for positioning by UEs in RRC_INACTIVE state within the SRS positioning validity area:
· For the UL timing advance, further study the following options, including the DL reference timing for each option:
R1-2301969 Summary #3 for low power high accuracy positioning Moderator (CMCC)
From Friday session
Agreement
For the spatial relation of an SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state, further study the following options:
Agreement
For the power control of an SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state, further study the following options:
Final summary in R1-2302189.
R1-2300084 Signaling and procedures to support PRS/SRS BW aggregation Huawei, HiSilicon
R1-2300227 Discussion on bandwidth aggregation for positioning measurements Spreadtrum Communications
R1-2300308 Discussion on bandwidth aggregation for positioning measurement OPPO
R1-2300462 Discussion on bandwidth aggregation for positioning measurements vivo
R1-2300585 Bandwidth aggregation for positioning measurement xiaomi
R1-2300689 Discussion on bandwidth aggregation for positioning measurements CATT
R1-2300779 Views on Bandwidth aggregation for positioning measurements Nokia, Nokia Shanghai Bell
R1-2300807 Discussion on BW aggregation for positioning ZTE
R1-2300957 On bandwidth aggregation for positioning measurements Intel Corporation
R1-2301011 Discussion on BW aggregation for positioning measurements CMCC
R1-2301068 Discussion on Bandwidth aggregation for positioning measurements LG Electronics
R1-2301137 Bandwidth aggregation for positioning measurements InterDigital, Inc.
R1-2301215 PRS/SRS Bandwidth Aggregation Aspects Lenovo
R1-2301273 On Bandwidth Aggregation for Positioning Measurements Samsung
R1-2301355 On Bandwidth aggregation for positioning measurements Apple
R1-2301422 Discussion on Bandwidth aggregation for Positioning Qualcomm Incorporated
R1-2301502 Discussion on bandwidth aggregation for positioning measurements NTT DOCOMO, INC.
R1-2301631 PRS/SRS aggregation for positioning measurement MediaTek Inc.
R1-2301683 Bandwidth aggregation for positioning measurements Ericsson
R1-2300809 Summary #1 for BW aggregation positioning Moderator (ZTE)
From Tuesday session
Agreement
To enable PRS bandwidth aggregation between PRS in two or three different PFLs, the following conditions should be satisfied for the aggregated PRS resources from a TRP across the aggregated PFLs:
Agreement
To enable SRS bandwidth aggregation between SRS in two or three carriers, the following conditions should be satisfied for the aggregated SRS resources across the aggregated carriers
R1-2300810 Summary #2 for BW aggregation positioning Moderator (ZTE)
From Wednesday session
Agreement
For PRS bandwidth aggregation across PFLs, support enhancement of PRS configuration to inform UE by LMF (or inform LMF by NG-RAN) PRS resources from which two or three PFLs are linked.
Agreement
Support joint measurement and report for the PRS resources aggregated across the PFLs for DL-TDOA and multi-RTT positioning methods
Agreement
For SRS bandwidth aggregation across two or three carriers, support enhancement of SRS configuration to indicate the SRS resources from which two or three carriers are linked
Agreement
Agreement
From RAN1 perspective, support UE performs PRS measurement across multiple aggregated PFLs in RRC_CONNECTED, RRC_INACTIVE and RRC_IDLE state.
R1-2302091 Summary #3 for BW aggregation positioning Moderator (ZTE )
From Friday session
Agreement
Support joint measurement and report for the SRS resources across the aggregated carriers for UL-TDOA and Multi-RTT positioning methods
Agreement
At least support periodic positioning SRS and semi-persistent positioning SRS for bandwidth aggregation
Agreement
Study potential power control enhancement of simultaneous transmission of SRS for SRS bandwidth aggregation especially in the case when the total uplink transmission power across multiple carriers exceeds P_c,max.
Agreement
Study the relationship between UL communication CA and SRS bandwidth aggregation, including
R1-2300069 On positioning for RedCap UEs in Rel-18 FUTUREWEI
R1-2300083 Discussion on frequency hopping for RedCap positioning Huawei, HiSilicon
R1-2300228 Discussion on positioning for RedCap Ues Spreadtrum Communications
R1-2300310 Discussion on positioning for RedCap UEs OPPO
R1-2300463 Discussion on positioning for RedCap UEs vivo
R1-2300690 Discussion on positioning for RedCap UEs CATT
R1-2300780 Views on Positioning for RedCap UEs Nokia, Nokia Shanghai Bell
R1-2300808 Discussion on Positioning for RedCap UEs ZTE
R1-2300833 Discussion on positioning support for RedCap UEs NEC
R1-2300883 Considerations on Positioning for RedCap UEs Sony
R1-2300958 Positioning for RedCap UEs Intel Corporation
R1-2301012 Discussion on RedCap UE positioning CMCC
R1-2301069 Discussion on positioning support for RedCap UEs LG Electronics
R1-2301138 Positioning for RedCap UEs InterDigital, Inc.
R1-2301216 RedCap Positioning Lenovo
R1-2301274 On Positioning for RedCap UEs Samsung
R1-2301356 On Positioning for RedCap UEs Apple
R1-2301423 Positioning for Reduced Capabilities UEs Qualcomm Incorporated
R1-2301503 Discussion on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2301632 Positioning for RedCap UEs MediaTek Inc.
R1-2301684 Positioning for RedCap Ues Ericsson
R1-2301727 Discussion on NR positioning for RedCap IIT Kanpur, CEWiT
R1-2301984 Feature Lead Summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
From Tuesday session
Conclusion
For positioning enhancements for RedCap UEs, only Rx frequency hopping of the DL PRS is supported.
Agreement
For RedCap UEs, support at least measurements on DL PRS with Rx frequency hopping using a measurement gap
· FFS: details on RedCap UE processing capabilities for DL PRS with Rx frequency hopping and MG
· FFS: the use of a single or multiple instances of a MGs
· FFS: the use of PPW
Conclusion
The scope for RedCap positioning includes FR1 and FR2.
R1-2301985 Feature Lead Summary #2 for Positioning for RedCap UEs Moderator (Ericsson)
From Wednesday session
Agreement
For Positioning enhancements for redcap UEs for UL SRS Tx and DL PRS Rx frequency hopping, from the RAN1 perspective, short switching time to allow RF retuning between adjacent hops may be beneficial in terms of accuracy and latency performance.
· Send an LS to RAN4 requesting feedback on the feasible values for the switching time between hops, at least when numerology and bandwidth for each hops can be the same, and the Tx/Rx antennas used in all hops can be the same.
Comeback for draft LS (see R1-2302126)
R1-2301986 Feature Lead Summary #3 for Positioning for RedCap UEs Moderator (Ericsson)
R1-2302210 Feature Lead Summary #4 for Positioning for RedCap UEs Moderator (Ericsson)
From Friday session
Agreement
For positioning for RedCap UEs with DL PRS Rx Hopping, the UE hops within a DL PRS resource
· FFS: whether there is specification update needed for RAN1
· FFS: remaining details
Agreement
For RedCap UEs, support SRS for positioning frequency hopping by
- Using a configuration separate from the existing BWP configuration
o FFS: hopping is configured within a SRS resource or across SRS resources
R1-2302126 Draft LS on switching time for DL PRS or UL SRS frequency hopping for RedCap UEs Morator (Ericsson)
Decision: The draft LS in R1-2302126 is endorsed with the addition of the two agreements above. Final LS is approved in R1-2302127.
For information:
R1-2302125 Draft LS discussion for DL PRS and UL SRS frequency hopping Switching time Moderator (Ericsson)
Please refer to RP-230328 for detailed scope of the WI. Aspects related to simultaneous measurements (see RAN1 LS reply to SA2 on PRU procedures) are to be handled in agenda 9.5.2.
R1-2304170 Session notes for 9.5 (Study on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
From AI 5
R1-2302282 LS on error source distributions RAN2, CATT
[112bis-e-R18-Pos-08] – Fumihiro (InterDigital)
Email discussion on RAN2 LS on error source distributions in R1-2302282 by April 26th
R1-2304100 Moderator summary on LS reply for error source distributions (R1-2302282) Moderator (InterDigital, Inc.)
From April 21st GTW session
Agreement
Parameters for the overbound Gaussian distribution can be mean and standard deviation.
Agreement
From RAN1 perspective, the value ranges of existing fields corresponding to quality information (e.g., nr-TimingQuality, rtd-Quality-r16) and uncertainty information (e.g., LocationUncertainty-r16) can be reused as a reference to derive the value ranges for the parameters (e.g., standard deviation) for the overbound Gaussian distribution for the error sources listed in Table 6.1.1-2 in TR 38.859.
Agreement
From RAN1’s perspective, zero is a valid possible option for the mean value for the overbound Gaussian distribution for the error sources listed in Table 6.1.1-2 in TR 38.859.
Agreement
From RAN1’s perspective, the RAN2 agreement “the error sources are overbounded by a Gaussian distribution” can be confirmed for the error sources listed in Table 6.1.1-2 in TR 38.859 if the error source follows a Gaussian distribution.
R1-2304146 [Draft] Reply LS to RAN2 on error source distributions Moderator (InterDigital, Inc.)
Decision: As per email decision posted on April 25th, the draft LS to RAN2 on error source distributions is endorsed. Final LS is approved in R1-2304147.
R1-2304243 RAN1 agreements for Rel-18 WI on Expanded and Improved NR Positioning Rapporteur (Intel Corporation)
From AI 5
R1-2302281 Reply LS on RAN dependency for Ranging & Sidelink Positioning RAN2, Xiaomi
[112bis-e-R18-Pos-09] – Qun (Xiaomi)
Email discussion on RAN2 LS on RAN dependency for ranging & sidelink positioning in R1-2302281by April 26th
- Check points: April 21, April 26
R1-2304092 Moderator summary on discussion of RAN2 LS in R1-2302281 on RAN dependency for Ranging & Sidelink Positioning Moderator (xiaomi)
From April 21st GTW session
Agreement
The draft LS response in Appendix of R1-2304092 is endorsed with the
following revision: NR_pos_enh2-Core.
R1-2304152 Reply LS on RAN dependency for Ranging & Sidelink Positioning RAN1, xiaomi
Decision: As per email decision posted on April 24th, the final LS is approved.
Including procedures related to transmit power control
R1-2302293 Design of SL positioning reference signal SL-PRS Nokia, Nokia Shanghai Bell
R1-2302326 Discussion on SL positioning reference signal FUTUREWEI
R1-2302377 Design on SL-PRS and power control Huawei, HiSilicon
R1-2302388 On sidelink positioning reference signal transmission coordination Continental Automotive
R1-2302490 Discussion on SL positioning reference signal vivo
R1-2302553 Discussion on SL positioning reference signal OPPO
R1-2302583 Discussion on SL positioning reference signal TOYOTA Info Technology Center
R1-2302605 Discussion on SL positioning reference signal Spreadtrum Communications
R1-2302708 Further discussion on SL positioning reference signal CATT, GOHIGH
R1-2302801 On SL Positioning Reference Signals Intel Corporation
R1-2302851 Discussion on SL positioning reference signal Sony
R1-2302874 Discussion on Sidelink Positioning Reference Signal Panasonic
R1-2302926 Discussion on SL positioning reference signal LG Electronics
R1-2302988 Discussion on sidelink positioning reference signal xiaomi
R1-2303027 Discussion on SL positioning reference signal China Telecom
R1-2303063 SL positioning reference signal Sharp
R1-2303133 On SL Positioning Reference Signal Samsung
R1-2303239 Discussion on SL positioning reference signal CMCC
R1-2303263 Discussion on SL PRS Aspects Lenovo
R1-2303276 Discussion on SL positioning reference signal ZTE
R1-2303306 Discussion on SL positioning reference signal design CEWiT
R1-2303414 Design considerations on SL positioning reference signal Fraunhofer IIS, Fraunhofer HHI
R1-2303443 SL-PRS design and power control for SL-PRS InterDigital, Inc.
R1-2303488 On SL positioning reference signal Apple
R1-2303550 SL positioning reference signal design Ericsson
R1-2303595 Reference Signal Design for SL Positioning Qualcomm Incorporated
R1-2303683 Discussion on SL positioning reference signal NEC
R1-2303784 Discussion on sidelink positioning reference signal ASUSTeK
R1-2303837 Reference signal design for sidelink positioning MediaTek (Chengdu) Inc.
[112bis-e-R18-Pos-01] – Debdeep (Intel)
Email discussion on SL positioning reference signal by April 26th
- Check points: April 21, April 26
R1-2303963 FL summary #1 on SL positioning reference signal Moderator (Intel Corporation)
Presented in April 19th GTW session
Decision: As per email decision posted on April 21st,
Agreement
For SL PRS sequence generation, no
additional parameters other than the following input parameters are used: slot
number, symbol number, and the parameter 
.
Agreement
TDM-based multiplexing in a slot of SL PRS from different UEs is NOT supported for a shared resource pool.
Decision: As per email decision posted on April 24th,
Agreement
SL PRS resource sets are not defined in Rel-18.
Agreement
(M, N) patterns with M > N with full staggering are supported.
Agreement
An AGC symbol preceding a SL PRS resource is not considered as part of the SL PRS resource itself.
Agreement
For the SL PRS open-loop power control, a UE can be configured to use DL pathloss (between TX UE and gNB) only, SL pathloss (between TX UE and RX UE) only, or both DL pathloss and SL pathloss.
· The same principle as for PSSCH power control is applied for deciding which (i.e., SL, DL, or SL and DL) pathloss to use.
· FFS: SL pathloss reference for open-loop power control for SL PRS.
R1-2303964 FL summary #2 on SL positioning reference signal Moderator (Intel Corporation)
From April 25th GTW session
Agreement
At least for dedicated SL PRS resource pools, in addition to already-agreed (M, N) = (2, 2), (4, 4), fully staggered pattern with (M, N) = (6, 6) is supported.
Agreement
NOTE 1: The above does not imply need for signalling/(pre-)configuration of all these parameters
Agreement
For
SL PRS sequence generation, one of the following options is down-selected to
define the parameter 
:
is
a higher layer parameter. is
based on 12 LSB bits CRC of PSCCH associated with the SL PRS.
Agreement
For a dedicated SL PRS resource pool, options for SL pathloss reference for OLPC for SL PRS are (to be down-selected from):
Decision: As per email decision posted on April 26th,
Agreement
For shared resource pools, a UE does not map SL-PRS and PSSCH DMRS in the same OFDM symbol(s).
Agreement
For SL pathloss-based OLPC for SL PRS in unicast, filtered RSRP is reported by a receiving UE.
R1-2303965 FL summary #3 on SL positioning reference signal Moderator (Intel Corporation)
From April 26th GTW session
Conclusion
For a partially staggered SL PRS pattern (M, N), repetition of a partially staggered SL PRS pattern (M, N) in a slot is not supported.
Final summary in R1-2304242.
R1-2302294 On measurements and reporting for SL positioning Nokia, Nokia Shanghai Bell
R1-2302327 Discussion on measurements and reporting for SL positioning FUTUREWEI
R1-2302378 Discussion on SL positioning measurement and reporting Huawei, HiSilicon
R1-2302491 Discussion on measurements and reporting for SL positioning vivo
R1-2302554 Discussion on measurements and reporting for SL positioning OPPO
R1-2302606 Discussion on measurements and reporting for SL positioning Spreadtrum Communications
R1-2302709 Further discussion on measurements and reporting for SL positioning CATT, GOHIGH
R1-2302802 Measurements and reporting for SL positioning Intel Corporation
R1-2302852 On Measurements and reporting for SL positioning Sony
R1-2302927 Discussion on measurements and reporting for SL positioning LG Electronics
R1-2302989 Discussion on measurements and reporting for SL positioning xiaomi
R1-2303064 Measurements and reporting for SL positioning Sharp
R1-2303134 On Measurements and Reporting for SL Positioning Samsung
R1-2303240 Discussion on measurements and reporting for SL positioning CMCC
R1-2303264 Discussion on SL Positioning Measurement and Reporting Lenovo
R1-2303277 Discussion on SL positioning measurements and reporting ZTE
R1-2303307 View on SL positioning measurements, measurements and reporting for SL positioning CEWiT
R1-2303415 Measurements and reporting for SL positioning Fraunhofer IIS, Fraunhofer HHI
R1-2303444 Measurement and reporting for SL positioning InterDigital, Inc.
R1-2303489 On Measurements and reporting for SL positioning Apple
R1-2303551 Measurements and reporting for SL positioning Ericsson
R1-2303596 Measurements and Reporting for SL Positioning Qualcomm Incorporated
R1-2303775 Solution for Carrier Phase based RTT Positioning Locaila
R1-2303842 Measurement and reporting design for sidelink positioning MediaTek (Chengdu) Inc.
[112bis-e-R18-Pos-02] – Peng (vivo)
Email discussion on measurements and reporting for SL positioning by April 26th
- Check points: April 21, April 26
R1-2303956 Summary #1 on Measurements and reporting for SL positioning Moderator (vivo)
From April 19th GTW session
Conclusion
Agreement
, where
Decision: As per email decision posted on April 20th,
Agreement
Support both the case with and without translation of the LCS to GCS for SL-PRS based Azimuth of arrival (AoA) and zenith of arrival (ZoA) measurement.
Agreement
SL Angle of Arrival (SL AoA) is defined as the estimated azimuth angle and vertical angle of a transmitting UE with respect to a reference direction, wherein the reference direction is defined:
The SL AoA is determined at the receiving UE’s antennas for a SL channel corresponding to the transmitting UE.
Agreement
Support SL-based RSTD, Rx-Tx time difference, RToA, AoA, RSRPP measurement and report for the first path and optionally additional path.
Decision: As per email decision posted on April 21st,
Agreement
For provision of assistance information for absolute SL positioning, the anchor UE location information can be provided to LMF or UE.
FFS: which UEs can receive the anchor UE location information (note: which may be decided by other WGs)
FFS on quality information of anchor UE location information.
Decision: As per email decision posted on April 24th,
Agreement
Support per ARP based measurement in sidelink positioning. The ARP related information can be reported along with the SL measurement.
FFS on details of ARP related information, including whether TEG ID can be reused for such purpose.
R1-2303957 Summary #2 on Measurements and reporting for SL positioning Moderator (vivo)
R1-2303958 Summary #3 on Measurements and reporting for SL positioning Moderator (vivo)
From April 25th GTW session
Agreement
For definition of SL-PRS based Rx-Tx measurement, further consider Alt1 and Alt3 until RAN1#113:
· Alt1: actual SL-PRS transmission time is used for the definition of SL-PRS based Rx-Tx time difference measurement
· Alt3: based on the Rel-16/17 definition for gNB Rx-Tx time difference/UE Rx-Tx time difference in Uu
Agreement
SL reference signal time difference (SL RSTD) is the SL relative timing difference between the UE j and the reference UE i, defined as TSubframe_SL-Rxj – TSubframe_SL-Rxi, where:
· TSubframe_SL-Rxj is the time when the UE receives the start of one subframe from UE j.
· TSubframeSL-Rxi is the time when the UE receives the corresponding start of one subframe from UE i that is closest in time to the subframe received from UE j.
FFS: whether or not impact due to mobility or synchronization timing change should be considered for SL RSTD
Decision: As per email decision posted on April 26th,
Agreement
Support higher layer signaling for sidelink positioning measurement report and report triggering.
· Up to RAN2 to discuss detailed signaling design.
FFS on SCI based report triggering.
Final summary in R1-2304240.
Including details related to the support of unicast/groupcast/broadcast of SL PRS transmissions.
R1-2302295 On resource allocation for SL positioning reference signal Nokia, Nokia Shanghai Bell
R1-2302328 Discussion on resource allocation for SL PRS FUTUREWEI
R1-2302379 Discussion on SL-PRS resource allocation Huawei, HiSilicon
R1-2302387 Considerations on resource allocation for sidelink positioning reference signal Continental Automotive
R1-2302492 Discussion on resource allocation for SL positioning reference signal vivo
R1-2302555 Discussion on resource allocation for SL positioning reference signal OPPO
R1-2302584 Discussion on resource allocation for SL positioning reference signal TOYOTA Info Technology Center
R1-2302607 Discussion on resource allocation for SL positioning reference signal Spreadtrum Communications
R1-2302710 Further discussion on resource allocation for SL positioning reference signal CATT, GOHIGH
R1-2302803 On resource allocation for SL positioning Intel Corporation
R1-2302853 Discussion on resource allocation for SL positioning reference signal Sony
R1-2302875 Discussion on Resource Allocation for SL-PRS Panasonic
R1-2302928 Discussion on resource allocation for SL positioning reference signal LG Electronics
R1-2302990 Discussion on resource allocation for SL positioning reference signal xiaomi
R1-2303028 Discussion on SL positioning reference signal resource allocation China Telecom
R1-2303065 Resource allocation for SL positioning reference signal Sharp
R1-2303135 On Resource Allocation for SL Positioning Reference Signal Samsung
R1-2303241 Discussion on resource allocation for SL positioning reference signal CMCC
R1-2303265 Discussion on SL Positioning Resource Allocation Lenovo
R1-2303278 Discussion on resource allocation for SL positioning reference signal ZTE
R1-2303308 Discussion on SL positioning resource allocation for SL positioning reference signal CEWiT
R1-2303416 Considerations on SL-PRS resource allocation Fraunhofer IIS, Fraunhofer HHI
R1-2303445 Resource allocation for SL positioning reference signal InterDigital, Inc.
R1-2303490 On Resource allocation for SL positioning reference signal Apple
R1-2303552 Resource allocation for SL positioning reference signal Ericsson
R1-2303597 Resource Allocation for SL-PRS Qualcomm Incorporated
R1-2303684 Discussion on resource allocation for SL positioning reference signal NEC
R1-2303786 Discussion on resource allocation for SL PRS ASUSTeK
R1-2303823 Considerations on resource allocation for SL positioning reference signal ITL
R1-2303838 Resource allocation for SL-PRS MediaTek (Chengdu) Inc.
[112bis-e-R18-Pos-03] – Alex (Qualcomm)
Email discussion on resource allocation for SL positioning RS by April 26th
- Check points: April 21, April 26
R1-2303978 Moderator Summary #1 on resource allocation for SL PRS Moderator (Qualcomm)
From April 19th GTW session
Agreement
For Scheme 1 SL-PRS resource allocation, a transmitting UE can receive a SL-PRS resource allocation signaling from gNB through a
Decision: As per email decision posted on April 20th,
Agreement
For a dedicated resource pool for positioning:
· No additional slots are needed to be supported.
Agreement
For SL-PRS transmission, either dedicated resource pool(s) or shared resource pool(s) or both can be (pre-)configured in the only SL BWP of a carrier.
· A UE can be (pre-)configured with one or more dedicated SL resource pools.
· A UE can be (pre-)configured with one or more shared SL resource pools.
Decision: As per email decision posted on April 23rd,
Agreement
Confirm the working assumption: Sensing-based and random selection can be allowed in the same resource pool.
Agreement
For Scheme 2 SL-PRS resource allocation, specify congestion control mechanisms using the existing congestion control mechanisms as a starting point.
Agreement
With regards to the SCI signaling in a shared resource pool, in addition to SL PRS transmission, the UE transmits
R1-2304067 Moderator Summary #2 on resource allocation for SL PRS Moderator (Qualcomm)
R1-2304140 Moderator Summary #3 on resource allocation for SL PRS Moderator (Qualcomm)
From April 25th GTW session
Agreement
In a shared resource pool:
Agreement
For a dedicated resource pool for SL positioning, only a single stage SCI is used. PSCCH and associated SL-PRS are TDMed in the same slot.
Agreement
For the scheme 2 sensing-based resource allocation, resolve the brackets below by:
R1-2304233 Moderator Summary #4 on resource allocation for SL PRS Moderator (Qualcomm)
From April 26th GTW session
Agreement
For Scheme 2, in a dedicated resource pool, using Rel-16 resource (re)-selection procedure as the starting point, consider at least the following potential modifications:
):
Agreement
In Scheme 2, with regards to the triggering of SL-PRS,
R1-2302380 Measurement and reporting for NR carrier phase positioning Huawei, HiSilicon
R1-2302493 Discussion on carrier phase positioning vivo
R1-2302524 Discussions on Carrier Phase Measurement for NR Positioning BUPT
R1-2302556 Discussions on NR carrier phase positioning OPPO
R1-2302608 Discussion on NR DL and UL carrier phase positioning Spreadtrum Communications
R1-2302711 Further discussion on NR DL and UL carrier phase positioning CATT
R1-2302804 On DL and UL carrier phase positioning Intel Corporation
R1-2302934 Views on NR DL and UL carrier phase positioning Nokia, Nokia Shanghai Bell
R1-2302991 NR DL and UL carrier phase positioning xiaomi
R1-2303136 On NR DL and UL Carrier Phase Positioning Samsung
R1-2303242 Discussion on DL/UL carrier phase positioning CMCC
R1-2303266 DL & UL Carrier Phase Positioning Discussion Lenovo
R1-2303279 Discussion on carrier phase positioning ZTE
R1-2303882 NR carrier phase measurements for positioning Fraunhofer IIS, Fraunhofer HHI (rev of R1-2303417)
R1-2303446 Discussion on positioning based on NR carrier phase measurement InterDigital, Inc.
R1-2303491 On NR DL and UL carrier phase positioning Apple
R1-2303553 NR DL and UL carrier phase positioning Ericsson
R1-2303598 NR Carrier Phase Positioning Qualcomm Incorporated
R1-2303717 Discussion on NR DL and UL carrier phase positioning NTT DOCOMO, INC.
R1-2303944 Discussion on carrier phase positioning in NR LG Electronics (rev of R1-2303744)
R1-2303774 Discussion on integer number resolution Locaila (Late submission)
R1-2303821 Discussion on NR UL and DL carrier phase positioning IIT Kanpur, CEWiT
R1-2303841 Solutions for carrier phase positioning MediaTek (Chengdu) Inc.
[112bis-e-R18-Pos-04] – Ren (CATT)
Email discussion on NR DL and UL carrier phase positioning by April 26th
- Check points: April 21, April 26
R1-2303888 FL Summary #1 for NR DL and UL carrier phase positioning Moderator (CATT)
Presented in April 17th GTW session.
Decision: As per email decision posted on April 21st,
Agreement
Introduce DL reference carrier phase (DL RSCP) and NR DL reference carrier phase difference (DL RSCPD) as DL carrier phase measurements.
· Note: It is up to RAN4 to decide whether and how to define the requirements for DL RSCP and/or DL RSCPD. No LS needed to RAN4 for this note.
· DL RSCP can be reported together with UE Rx – Tx time difference measurement
· DL RSCPD can be reported together with RSTD measurement
· FFS: details on how to eliminate unknown initial Rx phase with RSCP/RSCPD reporting can be further discussed
· Note: Whether to support standalone DL RSCP and/or DL RSCPD reporting, or DL RSCP/DL RSCPD reporting with other new types of measurements (if agreed), can be further discussed.
R1-2303889 FL Summary #2 for NR DL and UL carrier phase positioning Moderator (CATT)
From April 21st GTW session
Agreement
Support one of the following options for the definition of the reference point of the UE/TRP carrier phase measurements (down-selection in RAN1#113).
Agreement
To enable simultaneous transmission of UL SRS for positioning by a target UE and a PRU, support the following enhancements:
· Enabling LMF to request the serving gNB of a UE to configure the transmission of the [indicated] UL SRS resources from the UE within indicated time window(s).
o FFS: the details of the time window, e.g., the start time, duration, periodicity for the time window(s), within the vicinity of a reference SRS configuration or use the existing message of Scheduled Location time
· Enabling LMF to request the serving gNB and neighboring gNBs of the UE to measure the [indicated] UL SRS resources from the UE within indicated time window(s).
o Note: this may be a different indicated time window
Agreement
To enable simultaneous measurements on same DL PRS by a target UE and a PRU, support the following enhancements:
· Enabling LMF to request the UEs, including target UE and PRU(s), to perform measurements on [indicated] DL PRS resources occurring within indicated time window(s).
· FFS: the details of the configuration of the indicated time window(s), e.g., the start time, duration, periodicity for the time window(s), as well as the relationship with the Scheduled Location time.
Support the reuse of existing physical layer procedures for DL positioning (e.g., DL-TDOA) with the necessary enhancements in measurement configuration, request and report (e.g., adding the configuration related to the NR DL CPP) for both UE-based and UE-assisted NR DL carrier phase positioning, including
· UE in RRC_CONNECTED state with measurement gap.
· FFS: UE in RRC_CONNECTED state without measurement gap
· UE in RRC_INACTIVE state
Decision: As per email decision posted on April 25th,
The specific RF frequency associated with a DL carrier phase measurement is defined as the center frequency of the DL PFL by default.
· Note: It is open to further discussion whether a frequency other than the center frequency of the DL PFL can also be the specific RF frequency for non-default case(s), if RAN1 agrees to introduce them.
Agreement
The specific RF frequency associated with a UL carrier phase measurement is defined, by default, as the center frequency of the transmission bandwidth of the SRS for positioning purpose.
· Note: It is open to further discussion whether a frequency other than the center frequency of the UL carrier can also be the specific RF frequency for a non-default case(s), if RAN1 agrees to introduce them.
Agreement
· Support enabling a TRP to report UL RSCP together with RTOA and/or gNB Rx-Tx time difference measurements to LMF
· Note 1: The report of UL carrier phase measurement with gNB Rx – Tx time difference does not necessarily require the report of DL carrier phase measurement with UE Rx – Tx time difference.
· Note 2: This doesn’t preclude standalone UL carrier phase measurements reporting.
Agreement
Further study whether and how to support a UE/TRP to report the carrier phase measurement quality indication for corresponding the phase measurements.
Agreement
For NR UL carrier phase positioning for UE in RRC_CONNECTED and RRC_INACTIVE states, support reuse of existing physical layer procedures for UL positioning (e.g., UL-TDOA), with necessary enhancements in the measurement configuration, measurement request and measurement report (e.g., the configuration related to the NR UL CPP).
· FFS: the details of the enhancements.
R1-2303890 FL Summary #3 for NR DL and UL carrier phase positioning Moderator (CATT)
From April 26th GTW session
Agreement
Adopt one of the following options for a timestamp associated with a reported RSCP/RSCPD measurement (make the decision in RAN1#113):
· Option 1:
o NR-TimeStamp, currently defined in TS 37.355, is reused as the timestamp with the granularity of a slot.
o FFS: Whether to clarify in the specification the reported RSCP/RSCPD value presents the RSCP/RSCPD of a specific OFDM symbol within the slot identified by the NR-TimeStamp.
· Option 2:
o NR-TimeStamp, currently defined in TS 37.355, should be enhanced to include the OFDM symbol index in a slot, as the timestamp for RSCP/RSCPD measurements.
To address the impact of the phase delays on Tx/Rx RF chains, support one or more of the following options (down-selection in RAN1#113):
· Option 1a: introduce the definition of UE/TRP Tx/Rx phase error groups (PEGs) for the Tx/Rx of DL PRS/UL SRS signals
o Rel-17 definitions of UE/TRP Tx/Rx TEGs can be used as the starting point for defining UE/TRP Tx/Rx PEGs.
o FFS: the details of \the UE/TRP Tx/Rx PEGs
· Option 1b: Introduce Tx/Rx RF antenna IDs or Tx/Rx RF chain IDs to identify the individual Tx/Rx RF chains for transmitting/receiving the DL PRS/UL SRS signals.
o FFS: the details of the Tx/Rx RF antenna IDs or Tx/Rx RF chain IDs
o Note: Device transmitting PRS or positioning SRS provides Tx antenna ID or Tx Chain ID. Device receiving PRS or positioning SRS provides Rx antenna ID or Rx Chain ID.
· Option 1c: introduce the report of ARP ID for the Rx/Tx of DL PRS/UL SRS signals.
o The transmission/reception associated with the same ARP ID is assumed from the same ARP.
o FFS: the maximum number of ARP IDs.
· Option 2: reuse or enhance the existing Rel-17 definitions of UE/TRP Tx/Rx TEGs with smaller margin value.
· Option 3: RAN1 sends an LS to RAN4, requesting RAN4 to consider whether there is a need to define the new UE/TRP Tx/Rx phase error groups (PEGs), introduce new IDs (e.g., Tx/Rx RF antenna IDs ) to present the phase delays for the Tx/Rx of DL PRS/UL SRS signals, or reuse or enhance the existing Rel-17 definitions of UE/TRP Tx/Rx TEGs with smaller margin value, and provide the definitions if RAN4 decides it is needed.
R1-2302330 On enhancements for Rel-18 NR LPHAP FUTUREWEI
R1-2302381 Physical layer aspects of LPHAP Huawei, HiSilicon
R1-2302431 Discussion on Low Power High Accuracy Positioning Quectel
R1-2302494 Discussion on low power high accuracy positioning vivo
R1-2302557 Discussion on low power high accuracy positioning OPPO
R1-2302609 Discussion on LPHAP (Low Power High Accuracy Positioning) Spreadtrum Communications
R1-2302712 Further discussion on Low Power High Accuracy Positioning CATT
R1-2302805 On support of LPHAP Intel Corporation
R1-2302854 Discussion on Low Power High Accuracy Positioning Sony
R1-2302935 Views on LPHAP Nokia, Nokia Shanghai Bell
R1-2302992 Discussion on Low Power High Accuracy Positioning xiaomi
R1-2303137 On Low Power High Accuracy Positioning Samsung
R1-2303243 Discussion on low power high accuracy positioning CMCC
R1-2303280 Discussion on low power high accuracy positioning ZTE
R1-2303447 Discussions on Low Power High Accuracy Positioning (LPHAP) techniques InterDigital, Inc.
R1-2303492 On Low Power High Accuracy Positioning Apple
R1-2303554 On Low Power High Accuracy Positioning Ericsson
R1-2303599 Discussion on LPHAP Positioning Qualcomm Incorporated
R1-2303676 Discussion on Low Power High Accuracy Positioning NEC
R1-2303718 Discussion on Low Power High Accuracy Positioning NTT DOCOMO, INC.
R1-2303745 Discussion on LPHAP in idle/inactive state LG Electronics
[112bis-e-R18-Pos-05] – Jingwen (CMCC)
Email discussion on low power high accuracy positioning by April 26th
- Check points: April 21, April 26
R1-2304000 Summary #1 for low power high accuracy positioning Moderator (CMCC)
From April 17th GTW session
Agreement
For SRS for positioning configuration in multiple cells for a UE in RRC_INACTIVE state, sequenceID in SRS for positioning configuration is commonly configured across cells within the validity area.
Working assumption
For the power control of an SRS for positioning configuration in multiple cells for a UE in RRC_INACTIVE state, support the following options:
· Option 1: Pathloss RS is absent in the configuration.
· Option 2: Pathloss RS is provided in the configuration.
Working assumption
For the spatial relation of an SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state, support that spatial relation information can be absent or present in the configuration.
R1-2304001 Summary #2 for low power high accuracy positioning Moderator (CMCC)
From April 21st GTW session
Agreement
Agreement
For the power control of an SRS for positioning configuration in multiple cells for a UE in RRC_INACTIVE state, when pathloss RS is absent in the configuration, the UE determines the pathloss RS using a RS resource obtained from the SS/PBCH block of the camping cell that the UE uses to obtain MIB as the pathloss RS.
Agreement
For the power control of an SRS for positioning configuration in multiple cells for a UE in RRC_INACTIVE state, when pathloss RS is provided in the configuration, support one or multiple of the following alternatives on how to configure pathloss RS (down-selection to be made in RAN1#113 meeting):
R1-2304002 Summary #3 for low power high accuracy positioning Moderator (CMCC)
Presented in April 26th GTW session.
R1-2302382 Discussion on PRS/SRS BW aggregation Huawei, HiSilicon
R1-2302495 Discussion on bandwidth aggregation for positioning measurements vivo
R1-2302558 Discussion on bandwidth aggregation for positioning measurement OPPO
R1-2302610 Discussion on bandwidth aggregation for positioning measurements Spreadtrum Communications
R1-2302713 Further discussion on bandwidth aggregation for positioning measurements CATT
R1-2302806 On bandwidth aggregation for positioning measurements Intel Corporation
R1-2302936 Views on Bandwidth aggregation for positioning measurements Nokia, Nokia Shanghai Bell
R1-2302993 Bandwidth aggregation for positioning measurement Xiaomi
R1-2303138 On Bandwidth Aggregation for Positioning Measurements Samsung
R1-2303201 Bandwidth aggregation for positioning measurements ETRI
R1-2303244 Discussion on BW aggregation for positioning measurements CMCC
R1-2303267 PRS/SRS Bandwidth Aggregation Aspects Lenovo
R1-2303281 Discussion on BW aggregation for positioning ZTE
R1-2303448 Bandwidth aggregation for positioning measurements InterDigital, Inc.
R1-2303493 On Bandwidth aggregation for positioning measurements Apple
R1-2303555 Bandwidth aggregation for positioning measurements Ericsson
R1-2303927 Discussion on Bandwidth aggregation for Positioning Qualcomm Incorporated (rev of R1-2303600)
R1-2303719 Discussion on bandwidth aggregation for positioning measurements NTT DOCOMO, INC.
R1-2303746 Discussion on Bandwidth aggregation for positioning measurements LG Electronics
R1-2303839 PRS/SRS aggregation for positioning measurement MediaTek (Chengdu) Inc.
[112bis-e-R18-Pos-06] – Chuangxin (ZTE)
Email discussion on bandwidth aggregation for positioning measurements by April 26th
- Check points: April 21, April 26
R1-2303285 Summary #1 for BW aggregation positioning Moderator (ZTE)
From April 17th GTW session
Agreement
Study whether single TRP Tx TEG ID or UE Rx TEG ID is applied across PRSs in aggregated PFLs for TEG information reporting, i.e. single TEG ID is reported across the aggregated PRS resources for TRP Tx TEG association reporting, or for UE Rx TEG ID reporting in the measurement reporting.
Agreement
For PRS bandwidth aggregation across PFLs, select one of the following options in RAN1#112bis-e meeting
Conclusion
The legacy definition of DL RSTD, UL RTOA, UE Rx-Tx time difference, gNB Rx-Tx time difference is reused with the assumption that the subframe timings of the intra-band contiguous carriers are the same.
Decision: As per email decision posted on April 21st,
R1-2304081 [Draft] LS on measurement definitions for positioning with bandwidth aggregation Moderator (ZTE)
Decision: The draft LS to RAN4 is endorsed. Final LS is approved in R1-2304082.
Agreement
Support aperiodic positioning SRS for bandwidth aggregation for UEs in RRC_CONNECTED state.
· FFS the details
R1-2303286 Summary #2 for BW aggregation positioning Moderator (ZTE)
From April 21st GTW session
Agreement
For PRS resources aggregated across PFLs for DL-TDOA and multi-RTT positioning methods, use similar signaling as the existing Rel-16/Rel-17 DL PRS measurement of single PFL with the necessary update.
Conclusion
The details for on-demand PRS on PRS bandwidth aggregation are up to RAN2 and RAN3.
Agreement
For SRS bandwidth aggregation between SRS in two or three carriers, the aggregated SRS resources are of the same SRS resource-Type.
Agreement
At least from UE capability perspective, the UE support of positioning SRS bandwidth aggregation in RRC_CONNECTED state is decoupled from the UE support of communication CA.
Agreement
Support
the same power prioritization between the aggregated carriers in the case when total UE transmit power
in a transmission occasion I exceeds 
Decision: As per email decision posted on April 24th,
Agreement
Introduce new UE capability(-ies) to support PRS bandwidth aggregation measurement
Agreement
Study whether single UE Tx TEG ID or TRP Rx TEG ID is applied across SRSs in aggregated carriers for TEG information reporting, i.e. single UE Tx TEG ID is reported across the aggregated SRS resources for UE Tx TEG association reporting, or for TRP Rx TEG ID reporting in measurement reporting.
R1-2304083 Summary #3 for BW aggregation positioning Moderator (ZTE)
Decision: As per email decision posted on April 26th,
Agreement
Positioning SRS bandwidth aggregation is supported for UEs in RRC_CONNECTED.
Positioning SRS bandwidth aggregation is supported for UEs in RRC_INACTIVE state.
· For the details, Rel-17 positioning SRS configuration for UE in RRC_INACTIVE state outside initial UL BWP can be the starting point
Agreement
From RAN1 perspective, MG-based bandwidth aggregation measurement is supported. Decide whether PPW is supported for PRS bandwidth aggregation measurement in RAN1#113 meeting.
· FFS the details for PPW if supported
Agreement
For the case when PRS in one of aggregated PFL is dropped, e.g. because of collision with SSB, select one of the following solutions for LMF based positioning
Agreement
For SRS bandwidth aggregation across two or three carriers, select one of the following options in RAN1#113 meeting
Agreement
For the SRS resources across aggregated carriers for UL-TDOA and Multi-RTT positioning methods, use similar signaling as the existing Rel-16/Rel-17 SRS measurement of single carrier with the necessary update
Agreement
For positioning SRS aggregation across CCs, if SRS in one of aggregated carriers is dropped in a symbol, select one of the following two options:
From April 26th GTW session
Agreement
For SRS bandwidth aggregation between SRS in two or three carriers, decide whether one or more of the following are needed for the aggregated SRS resources in RAN1#113 meeting
· The same timing advance offset or the same TAG
· The same antenna port from RAN1 specification perspective
· UE is expected to be configured with SRS resources that maintain a per-symbol uniformly spaced SRS pattern across aggregated bandwidths
· Others if any.
Agreement
For PRS bandwidth aggregation between PRS in two or three different PFLs, decide whether one or more of the following are needed for the aggregated PRS resources from a TRP in RAN1#113 meeting:
· The same number of PRS resource sets and/or resources per set for a TRP
· The same NR-DL-PRS-SFN0-Offset value
· UE is expected to be configured with PRS resources that maintain a per-symbol uniformly spaced PRS pattern across aggregated bandwidths
o FFS: a per-symbol uniformly spaced PRS pattern across aggregated bandwidths does not preclude dropping some REs in the guardband between two PFLs
· Others if any.
R1-2302329 On positioning for RedCap UEs in Rel-18 FUTUREWEI
R1-2302383 Discussion on positioning for RedCap UEs Huawei, HiSilicon
R1-2302496 Discussion on positioning for RedCap UEs vivo
R1-2302559 Discussion on positioning for RedCap UEs OPPO
R1-2302611 Discussion on positioning for RedCap Ues Spreadtrum Communications
R1-2302714 Further discussion on positioning for RedCap UEs CATT
R1-2302807 Positioning for RedCap UEs Intel Corporation
R1-2302855 Discussion on positioning for RedCap UEs Sony
R1-2302937 Views on Positioning for RedCap UEs Nokia, Nokia Shanghai Bell
R1-2303139 On Positioning for RedCap UEs Samsung
R1-2303245 Discussion on RedCap UE positioning CMCC
R1-2303268 RedCap Positioning Lenovo
R1-2303282 Discussion on Positioning for RedCap UEs ZTE
R1-2303449 Positioning for RedCap UEs InterDigital, Inc.
R1-2303494 On Positioning for RedCap UEs Apple
R1-2303556 Positioning for RedCap Ues Ericsson
R1-2303601 Positioning for Reduced Capabilities UEs Qualcomm Incorporated
R1-2303674 Discussion on positioning support for RedCap UEs NEC
R1-2303720 Discussion on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2303747 Discussion on positioning support for RedCap UEs LG Electronics
R1-2303822 Discussion on NR positioning for RedCap IIT Kanpur, CEWiT
R1-2303840 Positioning for RedCap UEs MediaTek (Chengdu) Inc.
[112bis-e-R18-Pos-07] – Florent (Ericsson)
Email discussion on positioning for RedCap UEs by April 26th
- Check points: April 21, April 26
R1-2304004 Feature Lead Summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
From April 17th GTW session
Agreement
For RedCap UEs, SRS for positioning Tx frequency hopping is configured (select one alternative):
· Alt 1: within one SRS for positioning resource
· Alt 2: across resources, within one SRS for positioning resource set
· Alt 3: across resource sets, with all resources in a set corresponding to the same hop sub-bandwidth
Decision: As per email decision posted on April 21st,
Conclusion
For the positioning of redcap UEs, for the DL PRS reception and UL SRS transmission, the maximum hopping bandwidth for a single hop is 20MHz for FR1 and 100MHz with FR2.
R1-2304005 Feature Lead Summary #2 for Positioning for RedCap Ues Moderator (Ericsson)
R1-2304006 Feature Lead Summary #3 for Positioning for RedCap Ues Moderator (Ericsson)
From April 21st GTW session
Agreement
For RedCap UEs, SRS for positioning Tx frequency hopping is configured within one SRS for positioning resource.
Agreement
For DL Rx hopping or UL Tx hopping, support the UE or gNB to report the following:
· A single measurement based on receiving multiple hops of the DL PRS or UL SRS for positioning
· One [or more] measurements where each measurement is associated with one received hop
· FFS: indication of how many received hops / which received hops where used in the measurement report.
· Note: no new measurement definition is introduced in RAN1
· FFS: conditions when the above measurements are reported, and whether the above measurements can be reported together
R1-2304007 Feature Lead Summary #4 for Positioning for RedCap Ues Moderator (Ericsson)
From April 26th GTW session
Agreement
For UL SRS Tx hopping, the frequency hopping pattern is configured with overlapping or non-overlapping hops.
Agreement
For RedCap UEs positioning transmitting the UL SRS with frequency hopping, regarding the collisions between other UL and DL signals/channels and the UL SRS with frequency hopping, study whether to support one or both of the following options, according to UE capabilities:
Final summary in R1-2304253.
Please refer to RP-230328 for detailed scope of the WI. Aspects related to simultaneous measurements (see RAN1 LS reply to SA2 on PRU procedures) are to be handled in agenda 9.5.2.
Rapporteur to provide initial input on higher layer signalling under agenda item 9.5. For input on higher layer signalling from any other source, please include it as part of your tdoc to relevant sub-agenda items.
R1-2306144 Session notes for 9.5 (Study on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
[113-R18-Pos] – Debdeep (Intel)
Email discussion on NR positioning
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2304827 Higher layer parameters for Rel-18 Positioning Intel Corporation
R1-2306237 FLS on list of RRC parameters on Rel-18 WI on expanded and improved NR positioning Rapporteur (Intel Corporation) (rev of R1-2304827)
R1-2306238 RAN1 agreements for Rel-18 WI on Expanded and Improved NR Positioning Rapporteur (Intel Corporation)
From AI 5
R1-2304332 LS on the RAT-dependent positioning integrity RAN2, OPPO
R1-2306109 Moderator summary on LS reply on the RAT-dependent positioning integrity (R1-2304332) Moderator (InterDigital, Inc.)
From Wednesday session
For Q0 (RAN2 working assumption)
Agreement
From RAN1’s perspective, no concerns are identified for the RAN2 working assumption “It is left to LMF implementation to decide the measurement error source bound distribution based on the measurement results from UE and/or NG-RAN”:
For Q1 (Beam related information as error sources)
Agreement
Regarding whether beam-related information (Beam Bore-Sight Direction and Beam Antenna Information) are error sources or not, RAN1 made the following conclusion in RAN1#111, “RAN1 could not reach consensus on whether beam information (NR-TRP -BeamAntennaInfo) and boresight direction of DL PRS (NR-DL -PRS -BeamInfo) are error sources or not for DL-AoD for UE -based positioning integrity mode.”, where the definition of “UE-based positioning integrity mode” can be found in Table 9.4.1.1.1 in TR 38.857.
For Q2 (Application of DNU flags for TRP/UE positioning measurements)
Agreement
As agreed in RAN1#110b-e, from RAN1 perspective, study of the application of DNU flag for determination of positioning integrity is within the scope of RAN2 discussion. Specification impact(s) of DNU flag(s) can be discussed in RAN2.
Comeback on Friday for draft LS
R1-2306156 Draft LS reply on the RAT-dependent positioning integrity Moderator (InterDigital, Inc.)
Decision: The draft LS in R1-2306156 is endorsed. Final LS is approved in R1-2306157.
From AI 5
R1-2304306 Reply LS to LS to SA2 on Sidelink positioning procedure SA2, xiaomi
R1-2306082 Moderator summary on discussion of SA2 LS in R1-2304306 on SL positioning procedure Moderator (xiaomi)
Agreement
RAN1 provides the following reply to SA2 and cc to RAN2:
“From RAN1 perspective, it is feasible to specify relative velocity in Rel-18. RAN1 assumes that there is no RAN1 specification impact.”
Comeback on Friday for draft LS
R1-2306140 Draft Reply LS on Sidelink positioning procedure Moderator (xiaomi)
Decision: The draft LS in R1-2306140 is endorsed. Final LS is approved in R1-2306208.
Final summary in R1-2306207 (Moderator summary (EOM) on discussion of SA2 LS in R1-2304306).
Including procedures related to transmit power control
R1-2304345 Design of SL positioning reference signal SL-PRS Nokia, Nokia Shanghai Bell
R1-2304365 Discussion on SL positioning reference signal FUTUREWEI
R1-2304411 Discussion on SL positioning reference signal TOYOTA Info Technology Center
R1-2304484 Discussion on SL positioning reference signal vivo
R1-2304562 Discussion on SL positioning reference signal Spreadtrum Communications
R1-2304621 Remaining issues on SL-PRS and power control Huawei, HiSilicon
R1-2304677 Considerations on some aspects of SL PRS Continental Automotive
R1-2304735 On SL positioning reference signal CATT, GOHIGH
R1-2304828 On SL Positioning Reference Signals Intel Corporation
R1-2304859 Discussion on SL positioning reference signal China Telecom
R1-2304906 Discussion on sidelink positioning reference signal xiaomi
R1-2304927 Discussion on SL positioning reference signal ZTE
R1-2304967 Discussion on Sidelink Positioning Reference Signal Panasonic
R1-2305003 Discussion on SL positioning reference signal NEC
R1-2305041 On SL Positioning Reference Signal Sony
R1-2305098 Discussion on SL positioning reference signal CMCC
R1-2305125 SL-PRS design and power control for SL-PRS InterDigital, Inc.
R1-2305168 Considerations on SL PRS sequence ID selection Philips International B.V.
R1-2305199 Design considerations on SL positioning reference signal Fraunhofer IIS, Fraunhofer HHI
R1-2305247 On SL positioning reference signal Apple
R1-2305341 Reference Signal Design for SL Positioning Qualcomm Incorporated
R1-2305427 Discussion on SL positioning reference signal OPPO
R1-2305518 On SL Positioning Reference Signal Samsung
R1-2305634 Discussion on SL positioning reference signal LG Electronics
R1-2305684 SL positioning reference signal Sharp
R1-2305701 Discussion on sidelink positioning reference signal ASUSTeK
R1-2305736 Discussion on SL PRS Design Lenovo
R1-2305829 SL positioning reference signal design Ericsson
R1-2305836 Reference signal design for sidelink positioning MediaTek (Chengdu) Inc.
R1-2305901 Further discussion on sidelink positioning reference signal design aspects CEWiT
R1-2305995 FL summary #1 on SL positioning reference signal Moderator (Intel Corporation)
From Tuesday session
Agreement
In a dedicated resource pool, a SL PRS resource is immediately preceded by an AGC symbol unless RAN1 explicitly agrees that an AGC symbol is not included for specific cases (if any).
Agreement
· In a dedicated resource pool, a SL PRS resource is immediately followed by a gap symbol at least:
o if the gap symbol corresponds to the last SL symbol of a slot.
o Note: the gap can be used at least for Tx/Rx switching
o FFS: when TDM of multiple SL PRS resources within a slot is enabled in the dedicated resource pool
· FFS: Other cases.
· FFS: for SL PRS resource in a shared resource pool.
Agreement
For a dedicated resource pool, at least the case where SL PRS bandwidth is same as resource pool bandwidth is supported.
Agreement
For a shared resource pool, SL PRS bandwidth is same as the bandwidth indicated for PSSCH.
R1-2305996 FL summary #2 on SL positioning reference signal Moderator (Intel Corporation)
From Thursday session
Agreement
For a shared resource pool
· A SL PRS resource refers to a time-frequency resource within a slot that is used for SL PRS transmission.
· Characteristics associated with a SL PRS resource in a slot of a shared resource pool include at least:
o SL PRS resource ID,
o SL PRS comb offset and associated SL PRS comb size (N),
o SL PRS starting symbol and number of SL PRS symbols (M),
o SL PRS frequency domain allocation
- SL PRS freq domain allocation is not used to identify a unique SL PRS resource ID
· A SL PRS resource is identified by a combination of SL PRS resource ID and a SL PRS frequency domain allocation. This combination is unique within a slot of a shared resource pool.
NOTE 1: The above does not imply need for signalling/(pre-)configuration of all these parameters
Conclusion
For a dedicated or shared resource pool, at least the following characteristics are NOT included as part of characteristics of a SL PRS resource:
· Periodicity, number of instances/repetitions of SL PRS
Agreement
Comb-based multiplexing of SL PRS resources from different UEs in a slot is NOT supported for shared resource pools.
Conclusion
TDM-ed SL PRS resources within a slot from a single UE in a dedicated/shared resource pool is not supported in Rel-18.
Agreement
Multiple (M,N) pairs within a slot in a dedicated resource pool is supported only when the different (M, N) pairs are always multiplexed via TDM to different sets of symbols in a slot. Only a single (M,N) value can be mapped within one TDM duration (i.e. one set of symbols).
R1-2305997 FL summary #3 on SL positioning reference signal Moderator (Intel Corporation)
From Friday session
Working assumption
is defined as
below:
is provided by higher layers
to a Tx UE 
is based on 12 LSB bits CRC
of PSCCH associated with the SL PRS
is based on 12 LSB bits CRC
of PSCCH associated with the SL PRS
Agreement
For a shared resource pool, SL PRS transmit power is same as that for PSSCH.
Agreement
For SL PRS in a shared resource pool, the symbols of a SL-PRS resource within a slot are consecutive symbols.
Final summary in R1-2306236.
R1-2304346 On measurements and reporting for SL positioning Nokia, Nokia Shanghai Bell
R1-2304366 Discussion on measurements and reporting for SL positioning FUTUREWEI
R1-2304485 Discussion on measurements and reporting for SL positioning vivo
R1-2304563 Discussion on measurements and reporting for SL positioning Spreadtrum Communications
R1-2304622 Remaining issues on SL positioning measurement and reporting Huawei, HiSilicon
R1-2304736 On measurements and reporting for SL positioning CATT, GOHIGH
R1-2304796 On measurements for SL positioning congestion control Continental Automotive
R1-2304829 On measurements and reporting for SL positioning Intel Corporation
R1-2304907 Discussion on measurements and reporting for SL positioning xiaomi
R1-2304928 Discussion on SL positioning measurements and reporting ZTE
R1-2305042 Discussion on measurements and reporting for SL positioning Sony
R1-2305099 Discussion on measurements and reporting for SL positioning CMCC
R1-2306040 Measurement and reporting for SL positioning InterDigital, Inc. (rev of R1-2305126)
R1-2305200 Measurements and reporting for SL positioning Fraunhofer IIS, Fraunhofer HHI
R1-2305248 On Measurements and reporting for SL positioning Apple
R1-2305342 Measurements and Reporting for SL Positioning Qualcomm Incorporated
R1-2305428 Discussion on measurements and reporting for SL positioning OPPO
R1-2305476 Discussion on SL positioning measurements and reporting BUPT (Late submission)
R1-2305519 On Measurements and Reporting for SL Positioning Samsung
R1-2305635 Discussion on measurements and reporting for SL positioning LG Electronics
R1-2305685 Measurements and reporting for SL positioning Sharp
R1-2305737 Discussion on SL Positioning Measurement and Reporting Lenovo
R1-2305830 Measurements and reporting for SL positioning Ericsson
R1-2305837 Measurement and reporting design for sidelink positioning MediaTek (Chengdu) Inc.
R1-2305902 View on measurements and reporting for SL positioning methods CEWiT
R1-2306097 Summary #1 on Measurements and reporting for SL positioning Moderator (vivo)
From Tuesday session
Agreement
For definition of SL-PRS based Rx-Tx measurement, the actual SL-PRS transmission time is used for the definition of SL-PRS based Rx-Tx time difference measurement if the UE optionally reports the Tx time information, otherwise use the Rel-16/17 definition for gNB Rx-Tx time difference/UE Rx-Tx time difference in Uu.
· FFS: details of the Tx time information
· FFS: whether additionally the network or LMF can request the UE to report the Tx time information
· Note: the value of Rx-Tx measurement is within [-0.5 0.5] ms
Agreement
For provision of assistance information for sidelink positioning, the ARP location information can be provided to LMF or UE.
· FFS: which UEs can receive the location information (note: which may be decided by other WGs)
· FFS: details on the location information, e.g., relative location information
· Note: different ARPs have their own location information
Agreement
For per ARP measurement
· The ARP ID of an ARP used for reception can be reported along with SL positioning measurement in measurement report. The ARP ID is used to uniquely identify an ARP associated with a UE
· FFS: UE can indicate whether different ARPs for Rx and Tx are used for UE Rx-Tx time difference, if the UE optionally reports the Tx time information
· FFS: ARP ID of an ARP used for transmission, and details if supported
Agreement
Support at least the following mechanism to mitigate the impact of synchronization errors between anchor UEs for SL-TDoA based measurement
· Exchange of synchronization information of anchor UEs between a UE and LMF or another UE.
· FFS detailed synchronization information. E.g: synchronization source, relative time difference (RTD), synchronization quality information
· FFS other mechanisms
R1-2306098 Summary #2 on Measurements and reporting for SL positioning Moderator (vivo)
From Thursday session
Agreement
Location information of the target UE based on sidelink positioning measurements can be reported at least to LMF.
· FFS: on whether quality information of location is included, e.g., uncertainty etc
· Up to other WGs to determine whether location information of the target UE can be reported to another UE
· Up to RAN2 for signaling details
· FFS: whether and how to report per ARP location information.
Agreement
For definition of SL-PRS based RSRP measurement in frequency range 2
· SL PRS-RSRP shall be measured based on the combined signal from antenna elements corresponding to a given receiver branch.
· If receiver diversity is in use by the UE, the reported SL PRS-RSRP value shall not be lower than the corresponding SL PRS-RSRP of any of the individual receiver branches.
For definition of SL-PRS based RSRPP measurement in frequency range 2
· SL PRS-RSRPP shall be measured based on the combined signal from antenna elements corresponding to a given receiver branch.
· If receiver diversity is in use by the UE, the reported SL PRS-RSRPP value shall not be lower than the corresponding SL PRS-RSRPP of any of the individual receiver branches.
Agreement
Support reporting parameters needed for converting LCS to GCS in a similar way as in TS 38.455.
·
The
translation of the LCS to GCS uses the set of angles 
(bearing angle), 
(downtilt angle), 
(slant angle), which can be
reported together with the AoA (ϕ) and ZoA (θ) in LCS.
Agreement
For provision of assistance information for SL AoA measurement, expected SL-AoA value and uncertainty range can be provided to measuring UE.
· No specification impact on how to set the uncertainty range
· From RAN1 perspective, no performance requirements are expected to be defined for the uncertainty range in Rel-18
Agreement
A time stamp associated to each SL positioning measurement within the report includes at least the followings:
· SFN, slot number, and optionally including nr-PhysCellID, nr-ARFCN, nr-CellGlobalID
o FFS if at least one of nr-PhysCellID, nr-ARFCN, nr-CellGlobalID is always included
· Or DFN and slot number
o FFS: sidelink synchronization identity
FFS: SL-PRS resource ID is included within the measurement report
FFS: symbol number
Agreement
When GNSS is used for synchronization reference, DFN Initialisation Time is defined based on Tref and OffsetDFN defined for sidelink communications (Subclause 5.8.12 in 38.331).
Agreement
For SL-PRS based RSTD measurement report, the reference UE information is included in measurement reporting.
· FFS: details of the reference UE information
Final summary in R1-2306099.
Including details related to the support of unicast/groupcast/broadcast of SL PRS transmissions.
R1-2304347 On resource allocation for SL positioning reference signal Nokia, Nokia Shanghai Bell
R1-2304367 Discussion on resource allocation for SL PRS FUTUREWEI
R1-2304412 Discussion on resource allocation for SL positioning reference signal TOYOTA Info Technology Center
R1-2304486 Discussion on resource allocation for SL positioning reference signal vivo
R1-2304564 Discussion on resource allocation for SL positioning reference signal Spreadtrum Communications
R1-2304623 Discussion on SL-PRS resource allocation Huawei, HiSilicon
R1-2304676 Considerations on resource allocation for SL positioning Continental Automotive
R1-2304737 On resource allocation for SL positioning reference signal CATT, GOHIGH
R1-2304830 On resource allocation for SL positioning Intel Corporation
R1-2304908 Discussion on resource allocation for SL positioning reference signal xiaomi
R1-2304929 Discussion on resource allocation for SL positioning reference signal ZTE
R1-2304968 Discussion on Resource Allocation for SL-PRS Panasonic
R1-2305004 Discussion on resource allocation for SL positioning reference signal NEC
R1-2305043 On Resource Allocation for SL Positioning Reference Signal Sony
R1-2305100 Discussion on resource allocation for SL positioning reference signal CMCC
R1-2305127 Resource allocation for SL positioning reference signal InterDigital, Inc.
R1-2305213 Considerations on SL-PRS resource allocation Fraunhofer IIS, Fraunhofer HHI
R1-2305249 On Resource allocation for SL positioning reference signal Apple
R1-2305343 Resource Allocation for SL-PRS Qualcomm Incorporated
R1-2305429 Discussion on resource allocation for SL positioning reference signal OPPO
R1-2305520 On Resource Allocation for SL Positioning Reference Signal Samsung
R1-2305636 Discussion on resource allocation for SL positioning reference signal LG Electronics
R1-2305686 Resource allocation for SL positioning reference signal Sharp
R1-2305702 Discussion on resource allocation for SL PRS ASUSTeK
R1-2305741 Discussion on SL Positioning Resource Allocation Lenovo
R1-2305785 Considerations on resource allocation for SL positioning ITL
R1-2305831 Resource allocation for SL positioning reference signal Ericsson
R1-2305839 Resource allocation for SL-PRS MediaTek (Chengdu) Inc.
R1-2305903 Further discussion on SL positioning resource allocation for SL positioning reference signal CEWiT
R1-2306067 Moderator Summary #1 on resource allocation for SL PRS Moderator (Qualcomm)
From Tuesday session
Agreement
For a dedicated resource pool for SL positioning, SL-PRS cannot be transmitted in a slot without associated PSCCH.
Agreement
PSSCH is not included in dedicated resource pool for SL positioning.
Agreement
With regards to the SCI signaling in a shared resource pool,
Agreement
In shared resource pools,
Agreement
In a shared resource pool, SL-PRS, associated PSCCH and PSSCH scheduled by the PSCCH are included in the same slot:
Agreement
In a shared resource pool, SL-PRS, associated PSCCH and PSSCH scheduled by the PSCCH are included in the same slot:
Agreement
For the shared resource pool, reuse the existing IUC signaling of both Scheme 1 and Scheme 2.
Conclusion
For Rel-18 sidelink positioning:
Conclusion
Do not support ACK/NACK feedback for SL-PRS or lower-layer feedback-based retransmissions in Release 18.
R1-2306124 Moderator Summary #2 on resource allocation for SL PRS Moderator (Qualcomm)
From Thursday session
Agreement
PSFCH is not included in dedicated resource pool for SL positioning.
Agreement
In the dedicated resource pool,
· with regards to the SL-PRS time-domain resource allocation within the resource pool support a
o SL-PRS-resource-based allocation
· SCI for SL-PRS should at least indicate the following values:
o Source ID
o Destination ID
o Resource reservation period
o SL-PRS Priority
o Cast type
o With regards to the SL-PRS configuration and/or SL-PRS time assignment information, select one alternative at RAN1#114:
§ Alt. 3.1: support a one-to-one mapping relationship between a PSCCH resource and an associated SL-PRS resource in the same slot.
· Note: In this case, there is no need of an explicit signaling of which SL PRS resource for the same slot
· Note: Same number of PSCCH resource(s) and SL-PRS resource(s)
§ Alt. 3.2: explicit signaling of SL PRS resource in the same slot
§ Alt. 3.3: support a mapping relationship between a PSCCH resource and one or more associated SL-PRS resource(s) in the same slot and explicit signaling of SL PRS resource
· Only a one-to-one mapping is used between a PSCCH resource and an associated SL-PRS resource in the same slot if explicit signalling is not used
o Note: with a one-to-one mapping, some SL-PRS resources might not be mapped
o FFS: details, including (pre)configuration
§ FFS: Whether and how to indicate SCI resource(s) or SL-PRS resource (s) for a future slot
o FFS: Additional information, e.g. SL-PRS request, Positioning Session ID, number of resource reservation periods
Agreement
In Scheme 2, with regards to the triggering of SL-PRS, confirm the related WA for shared and dedicated resource pools.
· With regards to the lower-layer signalling, support SCI associated with SL-PRS transmission
o FFS: whether this is enabled by (pre)configuration
· FFS: to support also SL-PRS
R1-2306171 Moderator Summary #3 on resource allocation for SL PRS Moderator (Qualcomm)
From Friday session
Agreement
For Scheme 2, in a dedicated resource pool,
Agreement
In dynamic grant type resource allocation in scheme 1,
Agreement
In Scheme 2, congestion control can restrict the range of parameters for SL PRS configuration per resource pool by CBR and priority. Consider further the following parameter(s):
Agreement
In a dedicated resource pool, with regards to the PSCCH, reuse the PSCCH channel structure of SL communications, at least with regards to the following aspects:
R1-2304487 Discussion on carrier phase positioning vivo
R1-2304565 Discussion on NR DL and UL carrier phase positioning Spreadtrum Communications
R1-2304624 Remaining issues for NR carrier phase positioning Huawei, HiSilicon
R1-2304738 On NR DL and UL carrier phase positioning CATT
R1-2304831 On carrier phase positioning Intel Corporation
R1-2304909 NR DL and UL carrier phase positioning xiaomi
R1-2304930 Discussion on carrier phase positioning ZTE
R1-2304970 Discussion on NR DL and UL carrier phase positioning Locaila
R1-2305101 Discussion on DL/UL carrier phase positioning CMCC
R1-2305129 Discussion on positioning based on NR carrier phase measurement InterDigital, Inc.
R1-2305177 Views on NR DL and UL carrier phase positioning Nokia, Nokia Shanghai Bell
R1-2305182 Discussion on NR UL and DL carrier phase positioning IIT Kanpur, CEWiT
R1-2305214 NR carrier phase measurements for positioning Fraunhofer IIS, Fraunhofer HHI
R1-2305250 On NR DL and UL carrier phase positioning Apple
R1-2305344 NR Carrier Phase Positioning Qualcomm Incorporated
R1-2305386 Discussion on carrier phase positioning in NR LG Electronics
R1-2305413 Discussions on NR carrier phase positioning OPPO
R1-2305521 On NR DL and UL Carrier Phase Positioning Samsung
R1-2305603 Discussion on NR DL and UL carrier phase positioning NTT DOCOMO, INC.
R1-2305742 DL & UL Carrier Phase Positioning Discussion Lenovo
R1-2305832 NR DL and UL carrier phase positioning Ericsson
R1-2305840 Solutions for carrier phase positioning MediaTek (Chengdu) Inc.
R1-2305970 FL Summary #1 for NR DL and UL carrier phase positioning Moderator (CATT)
From Wednesday session
Agreement
Support the following definition of the reference point of the UE/TRP carrier phase measurements:
· The reference point of the UE carrier phase measurements is defined the same as the reference point of RSTD for both frequency range 1 and frequency range 2.
· The reference point of the TRP carrier phase measurements is defined the same as the reference point of RTOA for both frequency range 1 and frequency range 2.
· Note: It is up to UE/TRP’s implementation on how to map the carrier phase to the reference point for measurement reporting.
Agreement
Adopt the following modifications on the agreements made in RAN1#112bis-e:
To enable simultaneous transmission of UL SRS for positioning by a target UE and a PRU, support the following enhancements:
· Enabling LMF to request the serving gNB of a UE to configure the transmission of the UL SRS resources from the UE within indicated time window(s).
o FFS: the details of the time window, e.g., the start time, duration, periodicity for the time window(s), within the vicinity of a reference SRS configuration or use the existing message of Scheduled Location time
· Enabling LMF to request the serving gNB and neighboring gNBs of the UE to measure the UL SRS resources from the UE within indicated time window(s).
o Note: this may be a different indicated time window
To enable simultaneous measurements on same DL PRS by a target UE and a PRU, support the following enhancements:
· Enabling LMF to request the UEs, including target UE and PRU(s), to perform measurements on indicated DL PRS resource sets occurring within indicated time window(s).
· FFS: the details of the configuration of the indicated time window(s), e.g., the start time, duration, periodicity for the time window(s), as well as the relationship with the Scheduled Location time.
Agreement
For UE-based carrier phase positioning, support enabling LMF to forward the DL carrier phase measurement reported by a PRU, with additional information of the same PRU to a target UE for UE-based carrier phase positioning in the positioning assistance data.
· Note: Whether the forwarded DL carrier phase measurement is DL RSCP and/or DL RSCPD depends at least on which of them is (are) supported by UE capability.
· additional information of the same PRU includes at least PRU location.
o FFS: additional PRU information, e.g. the AoD of PRU to each TRP, etc.
Agreement
If a UE reports RSCPD measurements together with RSTD measurements in a measurement report element, the reference TRP for RSCPD is the same as the reference TRP reported for RSTD.
· The target and the reference TRP are in the same PFL
R1-2305971 FL Summary #2 for NR DL and UL carrier phase positioning Moderator (CATT)
From Friday session
Agreement
From RAN1’s perspective, carrier phase positioning for UE in RRC_IDLE state is supported for UE-based and UE-assisted positioning in Rel-18.
Conclusion
From RAN1’s perspective, carrier phase positioning for UE in RRC_CONNECTED state without measurement gap is not supported in Rel-18.
Working assumption
To enable LMF to optionally request the serving gNB of a UE to configure the transmission of the UL positioning SRS resources from the UE within indicated time window(s), support:
Agreement
To enable LMF to request the serving gNB and neighboring gNBs of a UE to measure the UL SRS resources from the UE within indicated time window(s), each time window is defined with the following parameters:
Agreement
To enable LMF to request the UEs, including target UE and PRU(s), to perform measurements on indicated DL PRS resource set(s) occurring within indicated time window(s), each time window is defined with the following parameters:
Final summary in R1-2305972.
R1-2304369 On enhancements for Rel-18 NR LPHAP FUTUREWEI
R1-2304488 Discussion on low power high accuracy positioning vivo
R1-2304566 Discussion on LPHAP (Low Power High Accuracy Positioning) Spreadtrum Communications
R1-2304625 Remaining issues of SRS in multiple cells Huawei, HiSilicon
R1-2304739 On Low Power High Accuracy Positioning CATT
R1-2304747 Discussion on Low Power High Accuracy Positioning Quectel
R1-2304832 On low power high accuracy positioning Intel Corporation
R1-2304910 Discussion on Low Power High Accuracy Positioning xiaomi
R1-2304931 Discussion on low power high accuracy positioning ZTE
R1-2305002 Discussion on Low Power High Accuracy Positioning NEC
R1-2305044 Discussion on LPHAP Sony
R1-2305102 Discussion on low power high accuracy positioning CMCC
R1-2305131 Discussions on Low Power High Accuracy Positioning (LPHAP) techniques InterDigital, Inc.
R1-2305178 Views on LPHAP Nokia, Nokia Shanghai Bell
R1-2305251 On Low Power High Accuracy Positioning Apple
R1-2305345 Discussion on LPHAP Positioning Qualcomm Incorporated
R1-2305387 Discussion on LPHAP in idle/inactive state LG Electronics
R1-2305415 Discussion on low power high accuracy positioning OPPO
R1-2305522 On Low Power High Accuracy Positioning Samsung
R1-2305604 Discussion on Low Power High Accuracy Positioning NTT DOCOMO, INC.
R1-2305833 On Low Power High Accuracy Positioning Ericsson
R1-2306014 Summary #1 for low power high accuracy positioning Moderator (CMCC)
From Wednesday session
Agreement
For the power control of an SRS for positioning configuration in multiple cells for a UE in RRC_INACTIVE state, when pathloss RS is provided in the configuration, support:
· Alt. 2-1 (modified): Reuse the configuration of pathloss RS in Rel-17;
o FFS: A CD SSB or non-CD SSB can be configured as pathloss RS
o If the UE determines that the pathloss RS cannot be accurately measured, pathloss may be calculated based on the RS resources obtained from SS/PBCH block of the new camping cell that the UE uses to obtain MIB.
Agreement
For the spatial relation of an SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state, when the spatial relation information is provided in the configuration, support:
· Alt. 1-1: Reuse the configuration of spatial relation information in Rel-17.
o When the UE determines that the configured RS for the spatial relation information cannot be accurately measured, the UE suspends the transmission of the SRS for positioning resource.
R1-2306015 Summary #2 for low power high accuracy positioning Moderator (CMCC)
From Friday session
Agreement
For the determination of UL timing to transmit SRS for positioning by UEs in RRC_INACTIVE state within the SRS positioning validity area, support the following to determine a valid TA:
· The DL reference timing follows the DL timing of current camping cell.
· By default, UE maintains the TA from the last serving cell.
o UE can adjust its UL timing according to the change in DL reference timing.
· If configured by the network, subject to UE capability, UE autonomously adjusts the TA, when cell-reselection happens.
o Send LS to RAN4 asking about feasibility and necessary conditions (e.g. whether the above behaviour applies when the DL reference timing difference between the last camping cell and current camping cell exceeds a threshold and how UE adjusts it, or additional RRM procedure to obtain the timing difference).
R1-2306247 Draft LS on determination of UL timing to transmit SRS for positioning by UEs in RRC_INACTIVE states Moderator (CMCC)
Decision: The draft LS in R1-2306247 is endorsed. Final LS is approved in R1-2306248.
Final summary in R1-2306016.
R1-2304489 Discussion on bandwidth aggregation for positioning measurements vivo
R1-2304567 Discussion on bandwidth aggregation for positioning measurements Spreadtrum Communications
R1-2304626 Remaining issues on PRS/SRS BW aggregation Huawei, HiSilicon
R1-2304740 On bandwidth aggregation for positioning measurements CATT
R1-2304833 On bandwidth aggregation for positioning Intel Corporation
R1-2304911 Bandwidth aggregation for positioning measurement xiaomi
R1-2304932 Discussion on BW aggregation for positioning ZTE
R1-2305012 Discussions on Carrier Aggregation for NR Positioning BUPT
R1-2305103 Discussion on BW aggregation for positioning measurements CMCC
R1-2305132 Bandwidth aggregation for positioning measurements InterDigital, Inc.
R1-2305179 Views on Bandwidth aggregation for positioning measurements Nokia, Nokia Shanghai Bell
R1-2305252 On Bandwidth aggregation for positioning measurements Apple
R1-2305346 Discussion on Bandwidth aggregation for Positioning Qualcomm Incorporated
R1-2305388 Discussion on Bandwidth aggregation for positioning measurements LG Electronics
R1-2305414 Discussion on bandwidth aggregation for positioning measurement OPPO
R1-2305523 On Bandwidth Aggregation for Positioning Measurements Samsung
R1-2305605 Discussion on bandwidth aggregation for positioning measurements NTT DOCOMO, INC.
R1-2305743 PRS/SRS Bandwidth Aggregation Aspects Lenovo
R1-2305834 Bandwidth aggregation for positioning measurements Ericsson
R1-2305841 PRS/SRS aggregation for positioning measurement MediaTek (Chengdu) Inc.
R1-2304935 Summary #1 for BW aggregation positioning Moderator (ZTE)
From Wednesday session
Agreement
For PRS bandwidth aggregation between PRS in two or three different PFLs, the following are needed for the aggregated PRS resources for a TRP:
· UE expects to be configured with PRS resources that maintain a per-symbol uniformly spaced PRS pattern across aggregated bandwidths in frequency domain (Note: It does not preclude dropping some REs in the guardband between two PFLs).
Agreement
For PRS bandwidth aggregation across PFLs, support
Agreement
For PRS bandwidth aggregation across PFLs, in a measurement report element, support
Agreement
When an SRS resource configured within a CC without PUSCH/PUCCH is linked for aggregation with an SRS resource configured within an UL active BWP of a UL communication CC, a guard period is needed before and after the aggregated SRS transmissions.
Comeback on Friday for draft LS to RAN4 (including this and other relevant agreements)
R1-2306215 Draft LS to RAN4 on SRS and PRS bandwidth aggregation for positioning Modeator (ZTE)
Decision: The draft LS in R1-2306215 is endorsed. Final LS is approved in R1-2306216.
Agreement
For PRS bandwidth aggregation, with regards to the signaling in the location information request message, introduce the following:
Conclusion
For PRS bandwidth aggregation, PPW is not supported in Rel-18.
Agreement
When the UE receives a request to perform aggregated measurements,
Agreement
For SRS bandwidth aggregation between SRS in two or three carriers, the following is needed for the aggregated SRS resources
Agreement
For SRS bandwidth aggregation across two or three carriers, support
· Option 2: Per SRS resource set basis.
o Support new signaling to indicate which SRS resource sets across carriers are linked.
o It is assumed that the SRS resources across the linked SRS resource sets are linked if the conditions are satisfied. For the non-linked SRS resource sets, no aggregation is assumed even if the conditions are satisfied.
Agreement
To support intra-band contiguous SRS bandwidth aggregation for UE in RRC_INACTIVE state, frequency information (e.g. point A, offset to carrier) of one or two additional carriers with respective SRS configurations should be provided to the UE, where the newly introduced carrier(s) and the carrier of the initial BWP should be intra-band contiguous carriers.
Working assumption
For semi-persistent positioning SRS for bandwidth aggregation, a single MAC CE can activate or deactivate:
Note: the single spatial relation is indicated by the MAC CE for each of two or three aggregated SRS resources.
Send an LS to RAN2 to confirm the feasibility.
Comeback on Friday for draft LS to RAN2
R1-2306213 Draft LS to RAN2 on SRS bandwidth aggregation for positioning Moderator (ZTE)
Decision: Draft LS in R1-2306213 is endorsed with the following change:
ACTION: RAN1
respectfully asks RAN2 to check
the feasibility of the working assumption and take the above
information into account for their future
workinform RAN1 of RAN2’s
conclusion on the feasibility.
Final LS is approved in R1-2306214.
R1-2304936 Summary #2 for BW aggregation positioning Moderator (ZTE)
From Friday session
Agreement
For positioning SRS aggregation transmission in RRC_INACTIVE state, reuse Rel-17 prioritization rule of SRS outside initial BWP, i.e. SRS is dropped in the symbol(s) of all aggregated carriers where collision occurs.
Agreement
For a carrier including positioning SRS for aggregation,
Agreement
With regard to support of aperiodic positioning SRS for bandwidth aggregation for UEs in RRC_CONNECTED state, at least the existing Rel-17 DCI framework (i.e. use multiple DCIs schedule SRSs in multiple carriers) can be reused
Agreement
For SRS bandwidth aggregation across carriers, support
Final summary in R1-2304937.
From AI 5
R1-2304316 LS reply on switching time for DL PRS or UL SRS frequency hopping for RedCap UEs RAN4, Ericsson
R1-2306120 Summary of discussion on LS for DL PRS and UL SRS frequency hopping Switching time Moderator (Ericsson)
From Wednesday session
Agreement
Response to RAN4 on the need of additional switching time:
Comeback on Friday for draft LS
R1-2306118 Draft reply LS for DL PRS and UL SRS frequency hopping Switching time Moderator (Ericsson)
Decision: The draft LS in R1-2306118 is endorsed. Final LS is approved in R1-2306119.
R1-2304368 On positioning for RedCap UEs in Rel-18 FUTUREWEI
R1-2304490 Discussion on positioning for RedCap UEs vivo
R1-2304568 Discussion on positioning for RedCap UEs Spreadtrum Communications
R1-2304627 Remaining issues on positioning for RedCap UEs Huawei, HiSilicon
R1-2304741 On positioning for RedCap UEs CATT
R1-2304834 On positioning for RedCap UEs Intel Corporation
R1-2304933 Discussion on Positioning for RedCap UEs ZTE
R1-2304987 Discussion on positioning support for RedCap UEs NEC
R1-2305045 On Positioning for RedCap UEs Sony
R1-2305104 Discussion on RedCap UE positioning CMCC
R1-2305133 Positioning for RedCap UEs InterDigital, Inc.
R1-2305180 Views on Positioning for RedCap UEs Nokia, Nokia Shanghai Bell
R1-2305183 Discussion on NR positioning for RedCap IIT Kanpur, CEWiT
R1-2305253 On Positioning for RedCap UEs Apple
R1-2305961 Positioning for Reduced Capabilities UEs Qualcomm Incorporated (rev of R1-2305347)
R1-2305389 Discussion on positioning support for RedCap UEs LG Electronics
R1-2305416 Discussion on positioning for RedCap UEs OPPO
R1-2305524 On Positioning for RedCap UEs Samsung
R1-2305606 Discussion on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2305744 RedCap Positioning Lenovo
R1-2305835 Positioning for RedCap UEs Ericsson
R1-2305842 Positioning for RedCap UEs MediaTek (Chengdu) Inc.
R1-2306114 Feature Lead summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
From Wednesday session
Agreement
The previous agreement is updated as follows:
Agreement
For DL Rx hopping or UL Tx hopping, support the UE or gNB to report the following:
· A single measurement based on receiving multiple hops of the DL PRS or UL SRS for positioning
·
One [or more]
measurements where each a
measurement is associated with one received hop
· FFS: indication of how many received hops / which received hops where used in the measurement report.
· Note: no new measurement definition is introduced in RAN1
· FFS: conditions when the above measurements are reported, and whether the above measurements can be reported together
Agreement
From RAN1 perspective, for DL PRS Rx hopping, a single instance of a measurement gap is used for receiving all the hops for DL PRS with Rx frequency hopping.
Agreement
SRS Tx Frequency hopping is supported for both RRC_CONNECTED and RRC_INACTIVE state.
Agreement
For the SRS Tx hopping pattern configuration support at least the staircase pattern, including a wrapped staircase pattern.
R1-2306115 Feature Lead summary #2 for Positioning for RedCap Ues Moderator (Ericsson)
From Friday session
R1-2306226 [DRAFT] LS on the use of a single measurement gap for DL PRS with Rx hopping measurement Moderator (Ericsson)
Decision: The draft LS in R1-2306226 is endorsed with the following changes:
·
In the Rel-18 WI Expanded and Improved NR
Positioning, in the agenda item “Positioning for redcap UEs”, RAN1 is
agreed the use of a single instance of
a measurement gap for receiving all the hops for DL PRS with Rx frequency
hopping:
·
RAN1 kindly respectfully
asks RAN4
Final LS is approved in R1-2306227.
Agreement
For RedCap UEs positioning transmitting the UL SRS with frequency hopping, regarding the collisions between other UL and DL signals/channels and the UL SRS with frequency hopping, support both of the following options
Final summary in R1-2306116.
Please refer to RP-231460 for detailed scope of the WI. Aspects related to simultaneous measurements (see RAN1 LS reply to SA2 on PRU procedures) are to be handled in agenda 9.5.2. Including any input on higher layer signaling (provide input as part of tdoc in each sub-agenda item).
R1-2308545 Session notes for 9.5 (Study on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
Endorsed and contents incorporated below.
[114-R18-Pos] – Debdeep (Intel)
Email discussion on NR positioning
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2306838 Higher layer parameters for Rel-18 expanded and improved NR Positioning Rapporteur (Intel Corporation)
R1-2308483 FLS on list of RRC parameters on Rel-18 WI on expanded and improved NR positioning Rapporteur (Intel Corporation)
R1-2308484 RAN1 agreements for Rel-18 WI on Expanded and Improved NR Positioning Rapporteur (Intel Corporation)
Including procedures related to transmit power control.
R1-2306441 Discussion on SL positioning reference signal FUTUREWEI
R1-2306451 Design of SL positioning reference signal SL-PRS Nokia, Nokia Shanghai Bell
R1-2306494 Finalizing SL-PRS design Huawei, HiSilicon
R1-2306558 Discussions on SL positioning reference signal Ruijie Network Co. Ltd
R1-2306649 Discussion on SL positioning reference signal Spreadtrum Communications
R1-2306686 Discussion on SL positioning reference signal design TOYOTA InfoTechnology Center
R1-2306754 Discussion on SL positioning reference signal vivo
R1-2306839 On SL Positioning Reference Signals Intel Corporation
R1-2306862 Discussion on SL positioning reference signal ZTE
R1-2306912 Remaining issues on SL Positioning Reference Signal Sony
R1-2307091 Remaining issues on SL positioning reference signal CATT, GOHIGH
R1-2307123 Discussion on SL positioning reference signal NEC
R1-2307199 Discussion on SL positioning reference signal CMCC
R1-2307282 On SL positioning reference signal Apple
R1-2307389 Discussion on sidelink positioning reference signal xiaomi
R1-2307537 Discussion on SL positioning reference signal OPPO
R1-2307584 SL-PRS design and power control for SL-PRS InterDigital, Inc.
R1-2307620 Discussion on SL positioning reference signal China Telecom
R1-2307682 On SL Positioning Reference Signal Samsung
R1-2307823 Remaining issues on SL PRS Design Lenovo
R1-2307852 SL positioning reference signal Sharp
R1-2307869 On Muting for Sidelink Positioning Reference Signals Continental Automotive
R1-2307930 Reference Signal Design for SL Positioning Qualcomm Incorporated
R1-2307981 Discussion on SL positioning reference signal LG Electronics
R1-2308005 Further discussion on sidelink positioning reference signal design CEWiT
R1-2308017 Discussion on sidelink positioning reference signal ASUSTeK
R1-2308096 Reference signal design for sidelink positioning MediaTek Korea Inc.
R1-2308166 SL positioning reference signal design Ericsson
R1-2308296 FL summary #1 on SL positioning reference signal Moderator (Intel Corporation)
From Tuesday session
Agreement (modified in Friday session as shown)
For TPC for PSCCH associated with SL PRS in dedicated resource pools down-select during RAN1 #114 from the following options:
·
Option A: Same symbol-level
Tx power between PSCCH and SL PRS. RAN1 to send an
LS to RAN4 requesting RAN4 to specify any necessary transient time.
o FFS: Additional limit on max PSCCH symbol power.
· Option B: Same Tx PSD between PSCCH and SL PRS
o FFS: Additional offset (≥ 0) to PSCCH Tx PSD.
Agreement
In a shared resource pool:
· Opt. B: SL PRS is mapped to contiguous symbols either before, between (as a working assumption), or after PSSCH DMRS symbols
Agreement
For a dedicated SL PRS resource pool, SL PRS is used as the pathloss reference for OLPC for SL PRS (Option 1 from RAN1 #112bis-e and RAN1 #113 meetings).
Agreement
Adopt the following update to the editor CR to TS 38.211, Section 8.4.1.6.1:
|
- |
Conclusion
For a dedicated resource pool, only the case where SL PRS bandwidth is the same as resource pool bandwidth is supported in Rel-18.
Agreement
For SL PRS in a dedicated resource pool, the following values of ‘M’ (number of SL PRS symbols) are supported: {1, 2, 3, …, 9}.
· In a dedicated resource pool, ‘M’ from {3, …, 9} are supported for cases with M > N with full staggering.
Agreement
For a dedicated resource pool, the maximum number of TDM groups for TDM-based multiplexing of SL PRS within a slot is 4.
· Maximum number 4 only applies to the case of comb-2.
R1-2308297 FL summary #2 on SL positioning reference signal Moderator (Intel Corporation)
R1-2308298 FL summary #3 on SL positioning reference signal Moderator (Intel Corporation)
From Thursday session
Agreement
For TPC for PSCCH associated with SL PRS in dedicated resource pools: same symbol-level Tx power between PSCCH and SL PRS.
Agreement
When an AGC symbol is transmitted immediately preceding a SL PRS resource, for generation of the AGC symbol:
· The RE offset in the AGC symbol is the same as that in the last symbol of the SL-PRS resource. The RS sequence is generated based on the symbol index of the AGC symbol within the slot.
Agreement
.
Friday comeback for draft LS
R1-2308558 Draft LS on Priority Handling for SL Positioning Moderator (Intel Corporation)
Decision: Endorse the draft LS in R1-2308558 with the following modification:
RAN1 also made the following conclusion related to priority and congestion control, and RAN1 expects the same handling of priorities for shared resource pool as the above agreement.
ACTION: RAN1 respectfully asks RAN WG2 to take the above agreement and conclusion into account when defining priority levels for SL PRS and PSSCH that are multiplexed in the same slot of a shared resource pool.
RAN1 respectfully
asks RAN WG2
to take the above conclusion into account for their work.
Final LS is approved in R1-2308559.
Agreement
For a dedicated resource pool, explicit (pre-)configuration of SL PRS resources in a slot includes:
Agreement
Update the following agreement as:
Agreement
For SL PRS in a dedicated or shared resource pool, for a given valid comb size ‘N’, partially staggered SL PRS patterns (M, N) are supported for all integer values of ‘M’ such that (M, N) = (1, 2) or (2, 4).
Conclusion
For a shared resource pool, no additional AGC or gap symbols are defined beyond those defined as part of Rel-16 SL communications, i.e., the only AGC symbol is the AGC symbol before the first symbol of the PSCCH and a gap symbol is present at the last SL symbol of the slot and/or a gap symbol is present in between PSSCH and PSFCH symbol when PSFCH is present in the slot.
Agreement
For a dedicated resource pool, no gap symbol for Tx-Rx switching is inserted in between two TDM-ed SL PRS resources within a slot when TDM of multiple SL PRS resources within a slot is enabled for the resource pool.
R1-2308482 FL summary #4 on SL positioning reference signal Moderator (Intel Corporation)
From Friday session
Agreement
For SL PRS, the comb offsets are defined as function of symbol index within a SL PRS resource as below.
|
Comb |
Symbol number within
the SL PRS resource |
||||||||
|
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
|
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
|
2 |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
|
4 |
0 |
2 |
1 |
3 |
0 |
2 |
1 |
3 |
0 |
|
6 |
0 |
3 |
1 |
4 |
2 |
5 |
0 |
3 |
1 |
Agreement
In a slot of shared resource pool, SL PRS is mapped after the last symbol with second stage SCI.
Working assumption
For a shared resource pool,
Final summary in R1-2308555.
R1-2306442 Discussion on measurements and reporting for SL positioning FUTUREWEI
R1-2306452 On measurements and reporting for SL positioning Nokia, Nokia Shanghai Bell
R1-2306495 Finalizing SL positioning methods and measurements Huawei, HiSilicon
R1-2306559 Discussions on measurements and reporting for SL positioning Ruijie Network Co. Ltd
R1-2306650 Discussion on measurements and reporting for SL positioning Spreadtrum Communications
R1-2306755 Discussion on measurements and reporting for SL positioning vivo
R1-2306840 On Measurements and Reporting for SL Positioning Intel Corporation
R1-2306863 Discussion on SL positioning measurements and reporting ZTE
R1-2306913 On measurements and reporting for SL positioning Sony
R1-2307092 Remaining issues on measurements and reporting for SL positioning CATT, GOHIGH
R1-2307200 Discussion on measurements and reporting for SL positioning CMCC
R1-2307283 On Measurements and reporting for SL positioning Apple
R1-2307390 Remaining issues on measurements and reporting for SL positioning xiaomi
R1-2307538 Discussion on measurements and reporting for SL positioning OPPO
R1-2307585 Measurement and reporting for SL positioning InterDigital, Inc.
R1-2307683 On Measurements and Reporting for SL Positioning Samsung
R1-2307824 Remaining SL Positioning Measurement and Reporting Issues Lenovo
R1-2307853 Measurements and reporting for SL positioning Sharp
R1-2307870 On Measurements for Sidelink Positioning Congestion Control Continental Automotive
R1-2307874 Discussion on SL positioning measurements and reporting BUPT
R1-2307931 Measurements and Reporting for SL Positioning Qualcomm Incorporated
R1-2307982 Discussion on measurements and reporting for SL positioning LG Electronics
R1-2308006 Discussion on measurements and reporting for SL positioning methods CEWiT
R1-2308097 Measurement and reporting design for sidelink positioning MediaTek Korea Inc.
R1-2308167 Measurements and reporting for SL positioning Ericsson
R1-2308360 Summary #1 on Measurements and reporting for SL positioning Moderator (vivo)
From Tuesday session
Agreement
For SL-PRS based Rx-Tx measurement, the Tx time information in the measurement report is the associated SL-PRS transmission timestamp.
Working assumption
Support to indicate to UE(s) with higher layer signaling to report multiple Rx-Tx measurements for the same SL PRS transmission (resp. reception) and different SL PRS receptions (resp. transmissions) for the same pair of UE(s).
· FFS: whether the different SL PRS receptions correspond to the same or different SL PRS resources
· Note: reporting a single Rx-Tx measurement is also supported
Agreement
To mitigate the impact of synchronization errors between anchor UEs for SL-PRS based measurement, the exchanged synchronization information of anchor UEs between a UE and LMF or another UE includes the following:
· [The synchronization source type (GNSS, gNB/eNB, and UE) of anchor UEs,
o If the synchronization source of an anchor UE is SyncRef UE, the anchor UE can optionally indicate the coverage status and synchronization connection status (whether the SyncRef UE is directly or indirectly synchronized to GNSS/gNB, or other SyncRef UE) of the SyncRef UE
o If the synchronization source of an anchor UE is gNB, the anchor UE can further provide cell identity information]
· [Synchronization quality/accuracy information]
· The RTD between anchor UEs.
Agreement
For provision of the ARP location information in assistance data for sidelink positioning, support the following:
· The ARP location information can be a position relative to a ‘reference point’.
· Note: RAN1 will not define “reference point”. The “reference point” definition can be up to other WGs.
R1-2308361 Summary #2 on Measurements and reporting for SL positioning Moderator (vivo)
From Wednesday session
Agreement
For location calculation, the ARP ID of SL PRS transmission can be informed to another UE or LMF by Tx UE informing the association between ARP ID and the already transmitted SL PRS resource(s) as assistance data.
Agreement
The following quality information can be reported in a similar way as in legacy Uu positioning:
· timing quality corresponding to the timing related measurements
· angle quality corresponding to the AoA measurement
·
No specification impact on how to set the quality information and from RAN1 perspective, no performance requirements are expected to be defined for the quality information in Rel-18.
It is up to RAN2 whether location quality information can be reported when location information is reported.
Agreement
For SL Positioning measurement report content, the following can be included:
· [SL PRS resource ID]
· ARP ID used for reception
· Measurement results
o Rx-Tx timing difference and quality
o RSTD measurement and quality
o RTOA measurement and quality
o AoA measurement and quality
o RSRP, RSRPP measurement
· Time stamp
o Rx timestamp
o Tx timestamp
· LoS/NLOS indicator
· [UE identity information or information related UE identity information]
Note1: unified or separate report for different SL positioning methods is up to other WGs (e.g., RAN2)
Note2: whether to include UE identity information or information related UE identity information is up to RAN2, including whether this is optional in the report.
Agreement
Regarding the reference point of SL-RTOA, support the following:
Regarding the reference point of SL-RSTD, support the following:
Agreement
For SL-PRS based Rx-Tx measurement, the same ARP is used for Rx and Tx for Rx-Tx time difference measurement.
Agreement
SL positioning measurements is applicable for RRC_CONNECTED and RRC_IDLE states.
· Note: if RRC_INACTIVE is supported for SL communication, then RRC_INACTIVE will be supported for SL positioning
R1-2308362 Summary #3 on Measurements and reporting for SL positioning Moderator (vivo)
From Thursday session
Agreement
Support to include the following in the exchanged synchronization information of anchor UEs between a UE and LMF or another UE:
R1-2308363 Summary #4 on Measurements and reporting for SL positioning Moderator (vivo)
From Friday session
Agreement
Support to include SL PRS resource ID in sidelink positioning measurement report.
Note: RAN1 will not further discuss how LMF/UE could use reported resource ID.
Final summary in R1-2308666.
Including details related to the support of unicast/groupcast/broadcast of SL PRS transmissions.
R1-2306443 Discussion on resource allocation for SL PRS FUTUREWEI
R1-2306453 On resource allocation for SL positioning reference signal Nokia, Nokia Shanghai Bell
R1-2306496 Finalizing SL PRS resource allocation Huawei, HiSilicon
R1-2306560 Discussions on resource allocation for SL positioning reference signal Ruijie Network Co. Ltd
R1-2306651 Discussion on resource allocation for SL positioning reference signal Spreadtrum Communications
R1-2306687 Discussion on resource allocation for SL positioning reference signal TOYOTA InfoTechnology Center
R1-2306756 Discussion on resource allocation for SL positioning reference signal vivo
R1-2306841 On Resource Allocation for SL Positioning Intel Corporation
R1-2306864 Discussion on resource allocation for SL positioning reference signal ZTE
R1-2306914 Considerations on resource allocation for SL positioning Sony
R1-2307093 Remaining issues on resource allocation for SL positioning reference signal CATT, GOHIGH
R1-2307124 Discussion on resource allocation for SL positioning reference signal NEC
R1-2307201 Discussion on resource allocation for SL positioning reference signal CMCC
R1-2307284 On Resource allocation for SL positioning reference signal Apple
R1-2307391 Remaining issues on resource allocation for SL positioning reference signal xiaomi
R1-2307539 Discussion on resource allocation for SL positioning reference signal OPPO
R1-2307586 Resource allocation for SL positioning reference signal InterDigital, Inc.
R1-2307621 Discussion on SL positioning reference signal resource allocation China Telecom
R1-2307684 On Resource Allocation for SL Positioning Reference Signal Samsung
R1-2307825 Remaining aspects for SL Positioning Resource Allocation Lenovo
R1-2307854 Resource allocation for SL positioning reference signal Sharp
R1-2307858 Discussion on Resource Allocation for SL-PRS Panasonic
R1-2307868 Considerations on Resource Allocation and Congestion Control for Sidelink Positioning Continental Automotive
R1-2307932 Resource Allocation for SL-PRS Qualcomm Incorporated
R1-2307983 Discussion on resource allocation for SL positioning reference signal LG Electronics
R1-2308007 On SL positioning resource allocation for SL positioning CEWiT
R1-2308016 Discussion on resource allocation for SL PRS ASUSTeK
R1-2308098 Resource allocation for sidelink positioning MediaTek Korea Inc.
R1-2308168 Resource allocation for SL positioning reference signal Ericsson
R1-2308184 Discussions on resource allocation for SL positioning ITL
R1-2308367 Moderator Summary #0 on resource allocation for SL PRS Moderator (Qualcomm)
From Tuesday session
Agreement
For SL-PRS transmissions without periodic reservation, the maximum number of reservations signaled in an SCI is
· (pre-)configurable with a value of 2 or 3, which is similar with Rel-16 sidelink.
This is applicable to both shared and dedicated resource pool and both scheme 1 and scheme 2.
Working assumption
In Scheme 2, with regards to the triggering of SL-PRS, for the SCI-based triggering, the SL-PRS request, in either SCI-1B or SCI-2D, is an explicit field
· If (pre-)configured per resource pool, then 1 bit is used, otherwise, it is 0 bits
Agreement
For dedicated resource pool, with regards to the SL-PRS configuration and/or SL-PRS time assignment information, support Alt. 3.1, i.e.
· support a one-to-one mapping relationship between a PSCCH resource and an associated SL-PRS resource in the same slot.
o Note: In this case, there is no need of an explicit signaling of which SL PRS resource for the same slot
o Note: Same number of PSCCH resource(s) and SL-PRS resource(s)
Agreement
For PSCCH configuration in a dedicated resource pool,
Agreement
For PSCCH configuration in a dedicated resource pool,
· The number of PSCCH symbol(s) is (pre-)configured to 2 or 3 symbols (same as legacy).
Agreement
In a shared resource pool, when PSSCH and SL-PRS are multiplexed in the same slot, they share the same source ID, destination ID, cast type fields.
Agreement
In a shared resource pool,
R1-2308426 Moderator Summary #1 on resource allocation for SL PRS Moderator (Qualcomm)
From Wednesday session
Agreement
Agreement
For Scheme 2, in a dedicated resource pool, with regards to the resource (re)-selection procedure, the RS used to derive L1 SL-RSRP for resource exclusion is at least PSCCH DMRS.
Working assumption
In the shared resource pool, if SL PRS is multiplexed in slot, for the determination of a transmission of a TB, the UE shall determine the number of REs (NRE) within the slot as
where 
represents the number of
OFDM symbols used for SL PRS in the slot.
The Tx UE should ensure the determined TB size unchanged across re-transmission(s) of the TB.
Agreement
In a shared resource pool,
Working assumption
For Scheme 2, in a dedicated resource pool, using Rel-16 resource (re)-selection procedure as the starting point, support the following modification:
Send an LS to RAN2 asking RAN2 whether they can confirm RAN1’s working assumption, and if not let RAN2 decide an alternative solution.
Friday comeback for draft LS.
R1-2308479 Draft LS on the resource selection window for Scheme 2 in a dedicated resource pool for positioning Moderator (Qualcomm)
Decision: Endorse the draft LS in R1-2308479 with the following modification to the action and adding SA2 in cc:
Change the Action Item as follows:
RAN1 respectfully asks RAN2 whether they can confirm RAN1’s working assumption, and if not, RAN1 requests RAN2 to decide an alternative solution and inform RAN1.
Final LS is approved in R1-2308651.
R1-2308471 Moderator Summary #2 on resource allocation for SL PRS Moderator (Qualcomm)
From Thursday session
Agreement
With regards to PSSCH and SL-PRS TDMed
multiplexing, when determining the number of coded modulation symbols generated
for 2nd-stage SCI transmission, symbols with SL-PRS are excluded when
calculating 
,
· Alt. 1: based on a value (pre-)configured in the resource pool for this purpose (new parameter).
· FFS: possible values (to be decided when discussing RRC parameters).
Agreement
From RAN1 perspective, for scheme 1 SL-PRS resource allocation for a UE requiring to transmit SL-PRS, the serving gNB may receive a request for specific SL PRS resource characteristic(s)/SL-PRS resource configuration(s).
Agreement
In a shared resource pool, with regards to the fields in SCI format 2-D, include the following fields:
Agreement
For the PSCCH configuration in a dedicated resource pool,
Agreement
For Scheme 2 SL-PRS resource allocation, with regards to the congestion control for a dedicated RP, the following modifications are supported:
Agreement
For Scheme 2 SL-PRS resource allocation, with regards to the congestion control for a dedicated RP, the following modifications are supported:
Agreement
For Scheme 2 SL-PRS resource allocation, with regards to the congestion control for a dedicated RP, the following modifications are supported:
o it can be separately configured for a dedicated resource pool and could take the legacy values
Agreement
In Scheme 2,
Agreement
In the dedicated resource pool for positioning, with regards to the SCI for SL-PRS, information carried in SCI for SL-PRS should at least include:
R1-2308572 Moderator Summary #3 on resource allocation for SL PRS Moderator (Qualcomm)
R1-2308627 Moderator Summary #4 on resource allocation for SL PRS Moderator (Qualcomm)
From Friday session
Agreement
In Scheme 2, with regards to the congestion control for SL PRS:
FFS: Whether it is needed to be reported to LMF or another UE
Agreement
For Scheme 2, in dedicated resource pools, with regards to the procedure for determining the subset of resources to be reported to higher layers, when triggering the resource (re-)selection procedure, the higher layers provide the following parameters for candidate SL-PRS transmission(s):
Agreement
For Scheme 2, in dedicated resource pools, with regards to the pre-emption,
Agreement
In resource allocation in scheme 1, for a dedicated resource pool
Conclusion
For Scheme 2 SL-PRS resource allocation, with regards to the congestion control for a shared RP, CBR and CR mechanisms from Rel.16 NR SL are reused.
Agreement
Support the following for SL-PRS multiplexing/collision with the following channels:
Working assumption
The number of bits in the embedded SCI format field of SCI format 2-D is 2 bits
Conclusion
In a shared resource pool, in the embedded SCI format of SCI format 2-D, there is no consensus to support the legacy content of SCI format 2-C.
Conclusion
For Scheme 2, in a dedicated resource pool, with regards to the resource (re)-selection procedure, there is no consensus to support to (pre-)configured SL-PRS to derive L1 SL-RSRP for resource exclusion.
R1-2306497 Remaining issues of carrier phase positioning Huawei, HiSilicon
R1-2306573 Discussions on NR DL and UL carrier phase positioning Ruijie Network Co. Ltd
R1-2306652 Discussion on NR DL and UL carrier phase positioning Spreadtrum Communications
R1-2306757 Discussion on carrier phase positioning vivo
R1-2306819 Views on NR DL and UL carrier phase positioning Nokia, Nokia Shanghai Bell
R1-2306842 On NR DL and UL Carrier Phase Positioning Intel Corporation
R1-2306865 Discussion on carrier phase positioning ZTE
R1-2306873 Remaining issues on NR DL and UL carrier phase positioning Locaila
R1-2306888 Discussion on carrier phase positioning in NR LG Electronics
R1-2307094 Remaining issues on NR DL and UL carrier phase positioning CATT
R1-2307202 Discussion on DL/UL carrier phase positioning CMCC
R1-2307285 On NR DL and UL carrier phase positioning Apple
R1-2307392 NR DL and UL carrier phase positioning xiaomi
R1-2307478 Discussion on NR DL and UL carrier phase positioning NTT DOCOMO, INC.
R1-2307522 Discussions on NR carrier phase positioning OPPO
R1-2307587 Discussion on positioning based on NR carrier phase measurement InterDigital, Inc.
R1-2307685 On NR DL and UL Carrier Phase Positioning Samsung
R1-2307826 Remaining DL/UL CPP Issues Lenovo
R1-2307933 NR Carrier Phase Positioning Qualcomm Incorporated
R1-2308093 Solutions for carrier phase positioning MediaTek Korea Inc.
R1-2308113 Discussion on NR DL/UL carrier phase positioning IIT Kanpur, CEWiT
R1-2308169 NR DL and UL carrier phase positioning Ericsson
R1-2308217 FL Summary #1 for NR DL and UL carrier phase positioning Moderator (CATT)
From Wednesday session
Agreement
Confirm the following working assumption with modification made in RAN1#113:
Working assumption
To enable LMF to optionally request the serving gNB of a UE to configure the transmission of the UL positioning SRS resources from the UE within indicated time window(s), support:
· Option 1D: Each of the time windows is defined with the following parameters:
o The
start of the time window, which is indicated by a combination of system
frame subframe number, slot offset and
symbol index with respect to the SFN initialization time
o The duration of the time window, which is given by a number of consecutive slots/symbols
§ FFS: the number of the consecutive slots/symbols
o (Optional) The periodicity of the time window, which is defined similar to IE PeriodicitySRS in “Requested SRS Transmission Characteristics” in TS 38.455.
· FFS: the maximum number of the windows
Agreement
When a LMF requests the serving gNB of a UE to configure the transmission of the UL positioning SRS resources from the UE within indicated time window(s),
Agreement
When a LMF requests the serving gNB and neighboring gNBs of a UE to measure the UL SRS resources from the UE within indicated time window(s):
Agreement
When an LMF requests the UEs, including target UE and PRU(s), to perform measurements on indicated DL PRS resource set(s) occurring within indicated time window(s)
Agreement
Each
DL RSCP/RSCPD measurement instance is obtained with 
sample only.
Conclusion
From RAN1’s perspective, the granularity and the range of the RSCP/RSCPD measurements can be defined by RAN4.
R1-2308218 FL Summary #2 for NR DL and UL carrier phase positioning Moderator (CATT)
From Friday session
Agreement
Endorse the following RAN1 reply on PRU procedures
RAN1 reply:
|
Current RAN1 specifications do not support a mechanism to ensure simultaneous measurements/transmissions (e.g. in the same slot(s)) for multiple UEs, including a target UE and a PRU. RAN1 will continue discussions on what enhancements to LPP, NRPPa, and/or RAN signaling are necessary to support simultaneous measurements of the same DL-PRS for multiple UEs, including a target UE and a PRU; and to support simultaneous transmission of SRS for multiple UEs, including a target UE and a PRU. Note: The enhancements might or might not have RAN1 specification impact. |
In above reply, RAN1 indicated that RAN1 would continue the discussions on the enhancements that are necessary to support simultaneous measurements of the same DL-PRS for multiple UEs, and the simultaneous transmission of SRS for multiple UEs, including a target UE and a PRU.
In this LS, RAN1 informs SA2 that RAN1 has continued the discussion, and reached the following agreements related to the support of simultaneous measurements of the same DL-PRS for multiple UEs and the simultaneous transmission of SRS for multiple UEs, including a target UE and a PRU.
Furthermore, it is RAN1’s understanding that
the simultaneous measurements/transmissions for multiple UEs, including a
target UE and a PRU, is closely relatedapplicable
to RAN1’s on-going work related to NR carrier phase positioning, and is
also applicable to the remaining uplink and downlink positioning
measurements and methods. Therefore, RAN1’s
agreements related to the NR carrier phase positioning are provided in Section
4 in this LS for information.
To SA2:
Action: RAN1 respectfully asks SA2 to take the above reply into account for future work.
To RAN2/RAN3:
Action: RAN1
respectfully asks RAN2/RAN3 to work on the necessary higher-layer
signalling support, and provide the feedback
if there is any concern.
R1-2308643 [Draft] Reply LS on PRU Procedures CATT
Decision: The draft LS is endorsed. Final LS is approved in R1-2308644.
Agreement
For the timestamp associated with a reported RSCP/RSCPD measurement, NR-TimeStamp, with the granularity of a slot, currently defined in TS 37.355, can be reused as the timestamp.
Agreement
When DL RSCPD/RSCP measurements are reported together with the DL RSTD/ UE Rx – Tx time difference measurements, the DL RSCPD/RSCP measurements are obtained from a single DL PFL only.
Note: From RAN1’s perspective, the reporting of the carrier phase measurements from one DL PFL has no impact on the reporting of the DL RSTD and/or UE Rx – Tx time difference measurements from the same DL PFL or other DL PFLs.
Agreement
For UE-based carrier phase positioning, when LMF forwards the DL carrier phase measurement reported by a PRU to a target UE, the timestamp associated with the PRU carrier phase measurements should also be forwarded in positioning assistance data.
Agreement
Support UE/TRP to report the phase quality indication for the RSCP/RSCPD measurements. The phase quality indication includes the following fields:
The values of the phase quality index and phase quality resolution are left for RAN4.
Final summary in R1-2308219.
From AI 5
R1-2306383 LS on LPHAP RAN2, Huawei
Decision: Discussion on response LS to be handled in agenda item 9.5.3. To be moderated by Jinhuan (Huawei).
R1-2308347 FLS on LPHAP LS reply Moderator (Huawei)
From Thursday session
Agreement
Suggest replying the first question that the eDRX cycle lengths agreed for eRedCap are sufficient for positioning in RRC_INACTIVE state.
Agreement
Suggest replying the second question as follows:
o RAN1 has agreed the following area-specific parameters for SRS for positioning configurations in a validity area:
· inactivePosSRS-TimeAlignmentTimer
· inactivePosSRS-RSRP-ChangeThreshold
· BWP parameters
o locationAndBandwidth
o subcarrierSpacing
o cyclicPrefix
· srs-PosConfig
o SRS-PosResourceSet
- srs-PosResourceSetId
- srs-PosResourceIdList
- resourceType
- p0 and alpha
- pathlossReferenceRS-Pos
o SRS-PosResource
- srs-PosResourceId
- transmissionComb
- resourceMapping
- freqDomainShift
- freqHopping
- groupOrSequenceHopping
- resourceType
- sequenceID
- spatialRelationInfoPos
o In addition, from RAN1’s perspective, the area-specific parameters should also include the following:
· A list of PCIs defining the positioning area
· autonomous TA adjustment enabler
R1-2308348 Draft reply LS on LPHAP Huawei
Decision: The draft LS in R1-2308348 is endorsed as a reply to RAN2. Final LS is approved in R1-2308349.
R1-2306445 On remaining open issues in LPHAP FUTUREWEI
R1-2306498 Remaining issues of physical layer aspects of LPHAP Huawei, HiSilicon
R1-2306653 Discussion on LPHAP (Low Power High Accuracy Positioning) Spreadtrum Communications
R1-2306758 Discussion on low power high accuracy positioning vivo
R1-2306820 Views on LPHAP Nokia, Nokia Shanghai Bell
R1-2306843 Support of LPHAP in NR Intel Corporation
R1-2306866 Discussion on low power high accuracy positioning ZTE
R1-2306878 Discussion on Low Power High Accuracy Positioning Quectel
R1-2306889 Discussion on LPHAP in idle/inactive state LG Electronics
R1-2306915 On Low Power High Accuracy Positioning Sony
R1-2307095 Remaining issues on Low Power High Accuracy Positioning CATT
R1-2307134 Discussion on Low Power High Accuracy Positioning NEC
R1-2307203 Discussion on low power high accuracy positioning CMCC
R1-2307286 On Low Power High Accuracy Positioning Apple
R1-2307393 Discussion on Low Power High Accuracy Positioning xiaomi
R1-2307479 Discussion on Low Power High Accuracy Positioning NTT DOCOMO, INC.
R1-2307524 Discussion on low power high accuracy positioning OPPO
R1-2307588 Discussions on Low Power High Accuracy Positioning (LPHAP) techniques InterDigital, Inc.
R1-2307686 On Low Power High Accuracy Positioning Samsung
R1-2307934 Discussion on LPHAP Positioning Qualcomm Incorporated
R1-2308092 LPHAP design MediaTek Korea Inc.
R1-2308170 On Low Power High Accuracy Positioning Ericsson
R1-2308305 Summary #1 for low power high accuracy positioning Moderator (CMCC)
From Wednesday session
Agreement
For SRS for positioning configuration in multiple cells for a UE in RRC_INACTIVE state, the power control parameters p0 and alpha per resource set are commonly configured across cells within the validity area.
Agreement
From RAN1 perspective, candidate values larger than 10240 ms for PRS and/or SRS periodicity, e.g., 20480 ms, can be introduced.
· FFS: specification impact on PRS/SRS configuration.
· Send LS to RAN2 asking them to work on the higher layer signalling details (e.g., specific values of periodicity, hyper SFN information in the configuration, etc.).
R1-2308306 Summary #2 for low power high accuracy positioning Moderator (CMCC)
From Friday session
R1-2308570 Draft LS on the longer PRS/SRS periodicity for LPHAP Moderator (Huawei)
Decision: The draft LS to RAN2/RAN3 in R1-2308570 is endorsed. Final LS is approved in R1-2308571.
Agreement
With regards to the reference RS for the RSRP change for TA validation:
R1-2308648 Draft LS on RSRP based TA validation for LPHAP Huawei
Decision: The draft LS in R1-2308648 is endorsed. Final LS is approved in R1-2308649.
Conclusion
For power control of an SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state, UE can be configured with a CD-SSB as the pathloss RS, or with a CD-SSB or NCD-SSB at least for RedCap UE as the pathloss RS. No specification impact is expected from RAN1 perspective.
Agreement
For spatial relation of an SRS for positioning configuration in multiple cells for UEs in RRC_INACTIVE state, on suspension of the transmission of an SRS resource for positioning, a UE is expected to keep monitoring the configured RS for spatial relation, and if the UE determines that it is being accurately measured, the UE resumes the SRS transmission.
Final summary in R1-2308307.
From AI 5
R1-2306363 LS reply on measurement definitions for positioning with bandwidth aggregation RAN4, Ericsson
Decision: Discussion on response LS to be handled in agenda item 9.5.4. To be moderated by Chuangxin (ZTE).
R1-2308448 Draft Reply LS on measurement definitions for positioning with bandwidth aggregation ZTE
Decision: The draft LS in R1-2308448 is endorsed as a reply to RAN2. Final LS is approved in R1-2308449.
R1-2306499 Remaining issues of BW aggregation for PRS and SRS Huawei, HiSilicon, China Unicom, China Telecom
R1-2306574 Discussions on bandwidth aggregation for positioning measurements Ruijie Network Co. Ltd
R1-2306654 Discussion on bandwidth aggregation for positioning measurements Spreadtrum Communications
R1-2306759 Discussion on bandwidth aggregation for positioning measurements vivo
R1-2306821 Views on bandwidth aggregation for positioning measurements Nokia, Nokia Shanghai Bell
R1-2306844 On bandwidth aggregation for positioning Intel Corporation
R1-2306867 Discussion on BW aggregation for positioning ZTE
R1-2306890 Discussion on Bandwidth aggregation for positioning measurements LG Electronics
R1-2307096 Remaining issues on bandwidth aggregation for positioning measurements CATT
R1-2307204 Discussion on BW aggregation for positioning measurements CMCC
R1-2307287 On Bandwidth aggregation for positioning measurements Apple
R1-2307394 Bandwidth aggregation for positioning measurement xiaomi
R1-2307480 Discussion on bandwidth aggregation for positioning measurements NTT DOCOMO, INC.
R1-2307523 Discussion on bandwidth aggregation for positioning measurement OPPO
R1-2307589 Bandwidth aggregation for positioning measurements InterDigital, Inc.
R1-2307687 On Bandwidth Aggregation for Positioning Measurements Samsung
R1-2307827 Remaining PRS Bandwidth aggregation issues Lenovo
R1-2307935 Discussion on Bandwidth aggregation for Positioning Qualcomm Incorporated
R1-2308094 PRS/SRS aggregation for positioning measurement MediaTek Korea Inc.
R1-2308171 Bandwidth aggregation for positioning measurements Ericsson
R1-2306870 Summary #1 for BW aggregation positioning Moderator (ZTE)
From Tuesday session
Agreement
For PRS/SRS bandwidth aggregation between two or three different PFLs/carriers, send a reply LS to request RAN4 to capture the condition of ‘the same RF chain (same antenna)’ in RAN4 specification.
Agreement
For the case when PRS in one of aggregated PFL is dropped because of collision with other signals, for LMF based positioning, it is up to UE implementation to perform positioning measurement based on one or more of the PRS resources in the aggregated PFLs.
· Note: it is up to RAN4 whether or not to define performance requirements for this case of collision with other signals.
Agreement
In RRC_CONNECTED state, for positioning SRS aggregation across CCs, if SRS in one of aggregated carriers is dropped in a symbol, stop SRS transmission in all aggregated carriers in the same symbol.
R1-2306871 Summary #2 for BW aggregation positioning Moderator (ZTE)
R1-2308450 Summary #3 for BW aggregation positioning Moderator (ZTE)
From Friday session
Agreement
Send an LS to RAN2 with the following content
With regards to higher layer parameter dl-PRS-ID, RAN1 understands that the current RAN2 specification support two interpretations:
· Interpretation 1: PRS resource sets in different PFLs of a TRP are configured with the same dl-PRS-ID
· Interpretation 2: PRS resource sets in different PFLs of a TRP can be configured with different dl-PRS-ID
For PRS bandwidth aggregation, RAN1’s agreement is that the linked PRS resource sets from two or three PFLs should be from the same TRP. RAN1 kindly requests RAN2 to capture the condition of the same TRP in RAN2 specifications for PRS bandwidth aggregation.
R1-2308645 Draft LS on TRP ID for positioning with bandwidth aggregation Moderator (ZTE)
Decision: Endorse the draft LS in R1-2308645 with the following modification to the action:
ACTION: RAN1 respectfully ask RAN2 to take the above information into consideration for their future work, and asks RAN2 to capture the condition of the same TRP in RAN2 specifications for PRS bandwidth aggregation.
Final LS is approved in R1-2308646.
Agreement
With regard to aperiodic positioning SRS for bandwidth aggregation for UEs in RRC_CONNECTED state, support both Option 2 and Option1.
· Option 2: Support to use a DCI format 0_3 or 1_3 for multi-cell PDSCH/PUSCH scheduling to trigger SRS resources for bandwidth aggregation in multiple CCs.
· Option 1: Support a Rel-17 single DCI scheduling positioning SRS resource sets across the linked carriers, as a separate UE capability.
o Reuse Rel-17 DCI framework without modification.
o If a single DCI indicates transmission of an aperiodic positioning SRS resource set, UE transmits aperiodic positioning SRS resource sets across all linked carriers for bandwidth aggregation.
R1-2306444 On remaining open issues in RedCap UE positioning FUTUREWEI
R1-2306500 Remaining issues of RedCap positioning Huawei, HiSilicon
R1-2306655 Discussion on positioning for RedCap UEs Spreadtrum Communications
R1-2306760 Discussion on positioning for RedCap UEs vivo
R1-2306822 Views on Positioning for RedCap Ues Nokia, Nokia Shanghai Bell
R1-2306845 Positioning for RedCap UEs Intel Corporation
R1-2306868 Discussion on Positioning for RedCap UEs ZTE
R1-2306891 Discussion on positioning support for RedCap UEs LG Electronics
R1-2306916 Remaining Issues on Positioning for RedCap UEs Sony
R1-2307097 Remaining issues on positioning for RedCap UEs CATT
R1-2307118 Positioning for RedCap UEs NEC
R1-2307205 Discussion on RedCap UE positioning CMCC
R1-2307288 On Positioning for RedCap UEs Apple
R1-2307481 Discussion on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2307525 Discussion on positioning for RedCap UEs OPPO
R1-2307590 Positioning for RedCap UEs InterDigital, Inc.
R1-2307688 On Positioning for RedCap UEs Samsung
R1-2307828 Remaining RedCap Positioning Issues Lenovo
R1-2307936 Positioning for Reduced Capabilities UEs Qualcomm Incorporated
R1-2308095 Positioning for RedCap UEs MediaTek Korea Inc.
R1-2308114 Discussion on NR positioning for RedCap IIT Kanpur, CEWiT
R1-2308172 Positioning for RedCap UEs Ericsson
R1-2308392 Feature Lead summary #1 for Positioning for RedCap Ues Moderator (Ericsson)
From Tuesday session
Agreement
PRS Rx frequency hopping for RRC_INACTIVE state and for RRC_IDLE state is supported for a RedCap UE.
Agreement
For the SRS Tx hopping, both hopping patterns (i.e. one cycle containing all the hops) that can span across slots or fit within one slot are supported.
· FFS: determination of the starting symbol position for each hop
· FFS: duration of each hop
Agreement
· RAN1#113 agreement is amended as follow
|
Agreement For RedCap UEs positioning transmitting the UL SRS with frequency hopping, regarding the collisions between other UL and DL signals/channels and the UL SRS with frequency hopping, support both of the following options - Option 1: UL time window where the UE is not expected to []transmit other signals/channels and is only expected to transmit FH SRS for positioning. - FFS details of an UL time window - Note: it implies that UE drops the transmission of other signals/channels and transmits SRS for positioning - Option 2: new collision rules between the UL SRS with frequency hopping and other UL and DL signals/channels/. Option 2 can apply without [or outside] UL time window (i.e. option 1) - FFS: details on the collision rules - Note: it is understood that option 2 is a component of the feature for UL SRS Tx hopping (FG 41-5-2), and option 1 is a separate feature group. |
R1-2308393 Feature Lead summary #2 for Positioning for RedCap Ues Moderator (Ericsson)
From Thursday session
Agreement
SRS for positioning with Tx hopping can be configured outside of the active UL BWP.
Agreement
For SRS Tx hopping, the configuration includes:
R1-2308394 Feature Lead summary #3 for Positioning for RedCap Ues Moderator (Ericsson)
From Friday session
Agreement
The UL time window for UL SRS for positioning with Tx hopping can be configured to be periodic with configurable starting SFN, slot and symbol number, periodicity, duration
· FFS values for starting SFN, slot and symbol number, periodicity and duration.
R1-2310542 Session notes for 8.3 (Maintenance on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
Friday decision: The session notes are endorsed and contents reflected below.
[114bis-R18-Pos] – Debdeep (Intel)
Email discussion on NR positioning
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2309194 Higher layer parameters for Rel-18 Expanded and Improved NR Positioning Rapporteur (Intel Corporation)
R1-2310592 Discussion on list of higher layer parameters on Rel-18 WI on expanded and improved NR positioning Rapporteur (Intel Corporation)
R1-2310593 RAN1 agreements for Rel-18 WI on Expanded and Improved NR Positioning Rapporteur (Intel Corporation)
From AI 5
R1-2308834 LS on SL positioning MAC agreements RAN2, Huawei
Decision: Discussion on response LS to be handled in agenda item 8.3.1 - Jinhuan (Huawei).
R1-2310400 FLS#1 on reply LS on SL positioning MAC CE agreements Moderator (Huawei)
Presented in Wednesday session
R1-2310536 FLS#2 on reply LS on SL positioning MAC agreement Moderator (Huawei)
From Thursday session
Agreement
Provide the response to Action2 as follows:
|
From RAN1 perspective, ·
The triggered UE’s higher layer will provide
the SL-PRS priority to lower layer as RAN1
agreed.
From RAN1’s perspective, whether the triggered UE
|
R1-2310401 Draft reply LS on SL positioning MAC CE agreements Moderator (Huawei)
Decision: The draft LS reply to RAN2 is endorsed in R1-2310401. Final LS is approved in R1-2310402.
R1-2308843 Remaining issues for design of SL positioning reference signal SL PRS Nokia, Nokia Shanghai Bell
R1-2308874 Maintenance of SL-PRS Huawei, HiSilicon
R1-2308983 Remaining issues on SL positioning reference signal Spreadtrum Communications
R1-2309071 Remaining issues on SL positioning reference signal vivo
R1-2309195 Remaining issues on SL Positioning Reference Signals Intel Corporation
R1-2309219 Maintenance on SL positioning reference signal ZTE
R1-2309245 Remaining issues on SL positioning reference signal LG Electronics
R1-2309287 Remaining issues on SL positioning reference signal NEC
R1-2309372 Maintenance on SL Positioning Reference Signal Samsung
R1-2309455 Remaining details on SL positioning reference signal xiaomi
R1-2309523 Maintenance on SL positioning reference signal CATT, CICTCI
R1-2309539 Maintenance on sidelink positioning reference signal ASUSTeK
R1-2309591 Remaining issues on SL positioning reference signal OPPO
R1-2309668 Maintenance on SL positioning reference signal CMCC
R1-2309771 Discussions on SL positioning reference signal Ruijie Network Co. Ltd
R1-2309780 Discussion on SL positioning reference signal design TOYOTA InfoTechnology Center
R1-2309795 Remaining issues on SL-PRS design and power control for SL-PRS InterDigital, Inc.
R1-2309830 On SL positioning reference signal Apple
R1-2309881 Remaining issues on SL positioning reference signal Sharp
R1-2309903 Remaining issues on SL Positioning Reference Signal Design Sony
R1-2309945 SL PRS Design Maintenance Aspects Lenovo
R1-2310089 Maintenance for SL-PRS design MediaTek Korea Inc.
R1-2310138 Maintenance for SL PRS Signal Design Qualcomm Incorporated
R1-2310195 Remaining issues on SL positioning reference signal design Ericsson
R1-2310333 FL summary #1 on SL positioning reference signal Moderator (Intel Corporation)
From Monday session
Conclusion
For SL PRS in a shared resource pool, in addition to the already-agreed values of ‘M’ = {1, 2, 4}, no new values are supported, i.e., ‘M’ can be from {1, 2, 4}.
Agreement
Confirm the working assumption from RAN1 #114 that in a shared resource pool SL PRS can be mapped to contiguous symbols between PSSCH DMRS symbols.
Agreement
For a dedicated resource pool, where SL PRS bandwidth is same as resource pool bandwidth, the following interpretation applies: SL PRS bandwidth corresponds to all PRBs of the resource pool bandwidth.
Agreement
Endorse the TP below for Section 8.2.4 of TS 38.214 for the parameters for SL PRS transmission in a shared resource pool.
|
Reason for change |
1. For a shared resource pool, “[SL PRS frequency domain allocation]” is not separately (pre-)configured and thus should not be listed as a parameter. However, it is still essential, along with SL PRS resource ID, in identifying a SL PRS resource in a slot of a shared resource pool. 2. For a shared resource pool, the starting symbol for SL PRS in a slot is derived based on specified rules and not provided as part of (pre-)configuration. Thus, “[Starting symbol and the number of SL PRS symbols]” should be updated to only “[number of SL PRS symbols]” for shared resource pools. |
|
Summary of change |
Section 8.2.4 in TS 38.214: 1. Clarify that for a shared resource pool, a SL PRS resource is uniquely identified by the SL PRS resource ID and the frequency domain resource allocation information that is obtained via the associated SCI. 2. Correct that “starting symbol” of a SL PRS resource is not a parameter for shared resource pool. |
|
Consequences if not approved |
Incorrect description of SL PRS resource pool (pre-)configuration parameters and SL PRS resource determination for shared resource pool. |
|
Text proposal |
------------------------------ TP#1: TS 38.214 ----------------------------------- 8.2.4 SL PRS transmission procedure The following parameters for SL PRS transmission are associated with each SL PRS resource: - [SL PRS resource ID] indicates an identity of a SL PRS resource. The SL PRS resource is identified by the SL PRS resource ID that is unique within a slot of a dedicated SL PRS resource pool. For a shared resource pool, a SL PRS resource is uniquely identified by a combination of the SL PRS resource ID and a SL PRS frequency domain allocation within a slot indicated by “frequency resource assignment” field in the associated SCI. - [SL PRS comb offset and comb size] indicates a comb offset and a comb size of the SL PRS resource - [Starting symbol and the number of SL PRS symbols] indicates the starting symbol index and the number of symbols of the SL PRS resource within a slot in a dedicated resource pool. [number of SL PRS symbols] indicates the number of symbols of the SL PRS resource within a slot in a shared resource pool. < Unchanged text omitted > |
Agreement
Endorse TP#4 in Section 6 of R1-2310333 for Section 8.4.1.6.3 of TS 38.211 to clarify the purpose of amplitude scaling factor for SL PRS.
Agreement
The following working assumption is confirmed without the FFS bullet as below:
·
For SL PRS sequence generation,
the parameter 
is defined as below:
o
is provided
by higher layers to a Tx UE
§ Details on higher layers, including consideration of Tx UE’s own higher layer, are up to RAN2
§
The higher layer parameter
is provided to an Rx UE via LPP/SLPP.
§
FFS:
If (pre-)configured for a resource pool and use of SL PRS for sensing is
supported, 
is based on 12 LSB bits CRC of PSCCH associated
with the SL PRS
·
Otherwise (i.e., if not
provided by higher layers), is
based on 12 LSB bits CRC of PSCCH associated with the SL PRS
R1-2310334 FL summary #2 on SL positioning reference signal Moderator (Intel Corporation)
From Wednesday session
Agreement
In a shared resource pool, a UE shall not transmit SL PRS and SL CSI-RS in the same symbol.
Note: the transmitting UE achieves this by either
· Not triggering SL CSI-RS
· If SL CSI-RS is triggered, then the symbols of SL CSI-RS cannot be used for SL PRS (per the earlier working assumption)
Agreement (confirmed on Thursday)
In a shared resource pool, transmission of SL PT-RS is cancelled in OFDM symbols with SL PRS.
Agreement
· The maximum number of SL PRS resources that can be (pre)configured in a slot of a dedicated resource pool is 12.
· The maximum number of SL PRS resources that can be (pre)configured in a slot of a shared resource pool is 17.
Agreement
Endorse the TP below for Section 8.2.1 of TS 38.211 to correct descriptions for the locations of guard symbols in shared and dedicated resource pools.
|
Reason for change |
1. In a slot of a shared resource pool, guard symbol may follow the last symbol of PSSCH, PSFCH or SL PRS. However, this is not captured accurately in current version of the specification text. 2. In a slot of a dedicated resource pool, guard symbol is the last symbol configured for sidelink. This is not reflected in the current version of the specification text. |
|
Summary of change |
Section 8.2.1 in TS 38.211: 1. Clarify that in a slot of a shared resource pool, guard symbol may follow the last symbol of PSSCH, PSFCH or SL PRS. 2. Clarify that in a dedicated SL PRS resource pool, the last symbol configured for sidelink serves as a guard symbol. |
|
Consequences if not approved |
Incorrect description of location(s) of guard symbols in shared and dedicated SL PRS resource pools. |
|
Text proposal |
------------------------------ TP#2: TS 38.211 ----------------------------------- 8.2.1 General In a shared resource pool, the OFDM symbol immediately preceding the symbols which are configured for use by PSFCH if PSFCH is configured in this slot, and the last symbol configured for sidelink in a slot, serve as guard symbol(s). In a dedicated SL PRS resource pool, the last symbol configured for sidelink in a slot serves as a guard symbol. Otherwise,
< Unchanged text omitted > |
Agreement
The TP below for Section 8.2.4 of TS 38.214 is endorsed.
|
Reason for change |
The following RAN1 agreements need to be captured in the RAN1 specifications. Agreement (RAN1 #113) Multiple (M,N) pairs within a slot in a dedicated resource pool is supported only when the different (M, N) pairs are always multiplexed via TDM to different sets of symbols in a slot. Only a single (M,N) value can be mapped within one TDM duration (i.e. one set of symbols). Agreement (RAN1 #114) For a dedicated resource pool, the maximum number of TDM groups for TDM-based multiplexing of SL PRS within a slot is 4. · Maximum number 4 only applies to the case of comb-2
|
|
Summary of change |
Section 8.2.4 in TS 38.214: Capture the (pre-)configuration of SL PRS resources in a dedicated resource pool for the case of TDM-based multiplexing as per the RAN1 agreements. |
|
Consequences if not approved |
Necessary details for (pre-)configuration of SL PRS resources in a dedicated resource pool with TDM-based multiplexing would not be reflected in the specifications. |
|
Text proposal |
------------------------------ TP#3: TS 38.214 ----------------------------------- 8.2.4 SL PRS transmission procedure The following parameters for SL PRS transmission are associated with each SL PRS resource: - [SL PRS resource ID] indicates an identity of a SL PRS resource. The SL PRS resource is identified by the SL PRS resource ID that is unique within a slot of a dedicated SL PRS resource pool. For a shared resource pool, a SL PRS resource is uniquely identified by a combination of the SL PRS resource ID and a SL PRS frequency domain allocation within a slot. - [SL PRS comb offset and comb size] indicates a comb offset and a comb size of the SL PRS resource - [Starting symbol and the number of SL PRS symbols] indicates the starting symbol index within a slot and the number of symbols of the SL PRS resource. - [SL PRS frequency domain allocation] indicates the frequency location [and the number of resource blocks for SL PRS transmission in a shared resource pool.]
For a dedicated SL PRS resource pool, SL PRS resources for a same
Each SL PRS transmission is associated with an PSCCH transmission in the same slot. In the case of dedicated pool for SL positioning, that PSCCH carries the SCI format 1-B associated with the SL PRS transmission. The UE may report the association information of the already transmitted SL PRS resources with UE Tx ARP ID. < Unchanged text omitted > |
From Thursday session
Agreement
Confirm the following working assumption from RAN1 #114 with the following update:
· For a shared resource pool,
o Explicit (pre-)configuration of SL PRS resources in a slot, applicable for an indicated frequency domain allocation, includes:
§ SL PRS Resource ID, (M, N) pattern, comb offset.
o
For a given value of ‘M’,
SL PRS resource is mapped to the last consecutive ‘M’ SL symbols in the slot
that can be used for SL PRS, i.e., taking into consideration multiplexing with
PSSCH DMRS, PT-RS, CSI-RS, PSFCH, gap symbols, AGC symbols, PSCCH in the slot
o The maximum number
of SL PRS resources in a slot of a shared resource pool that can be
(pre-)configured is FFS.
Final summary in R1-2310335.
R1-2308844 Remaining issues for measurements and reporting for SL positioning Nokia, Nokia Shanghai Bell
R1-2308875 Maintenance of SL measurements Huawei, HiSilicon
R1-2308984 Remaining issues on measurements and reporting for SL positioning Spreadtrum Communications
R1-2309072 Remaining issues on measurements and reporting for SL positioning vivo
R1-2309196 Remaining issues on SL Positioning Measurements and Reporting Intel Corporation
R1-2309220 Maintenance on SL positioning measurements and reporting ZTE
R1-2309246 Remaining issues on measurements and reporting for SL positioning LG Electronics
R1-2309293 Discussion on SL positioning measurements and reporting BUPT
R1-2309373 Maintenance on Measurements and Reporting for SL Positioning Samsung
R1-2309456 Remaining details on measurements and reporting for SL positioning xiaomi
R1-2309524 Maintenance on measurements and reporting for SL positioning CATT, CICTCI
R1-2309592 Remaining issues on measurements and reporting for SL positioning OPPO
R1-2309669 Maintenance on measurements and reporting for SL positioning CMCC
R1-2309796 Remaining issues on measurement and reporting for SL positioning InterDigital, Inc.
R1-2309831 On Measurements and reporting for SL positioning Apple
R1-2309904 Remaining Issues on SL positioning methods and measurements Sony
R1-2309946 Measurement and Reporting Maintenance Discussion Lenovo
R1-2310139 Maintenance for SL Positioning Measurements Qualcomm Incorporated
R1-2310196 Remaining issues on measurements and reporting for SL positioning Ericsson
R1-2310342 Summary #1 on Measurements and reporting for SL positioning Moderator (vivo)
From Monday session
Agreement
Confirm the following working assumption with update:
|
Working assumption Support to indicate to UE(s) with higher layer signaling to report multiple Rx-Tx measurements for the same SL PRS transmission (resp. reception) and different SL PRS receptions (resp. transmissions) for the same pair of UE(s).
· Note: reporting a single Rx-Tx measurement is also supported · Note: The indicated Rx-Tx time difference measurement is based on actual Tx time. |
Agreement
For SL RSTD measurement, reference UE information is the information needed to identify the reference UE
· Up to RAN2 to determine details
Agreement
Regarding the association information report between ARP ID and the already transmited SL PRS resource(s):
· The association information includes {ARP ID, Tx time stamp, SL PRS resource ID (optional)}.
R1-2310343 Summary #2 on Measurements and reporting for SL positioning Moderator (vivo)
From Wednesday session
Agreement
Support to indicate to UE(s) with higher layer signaling to report multiple Rx-Tx measurements for the same SL PRS transmission (resp. reception) and up to N different SL PRS receptions (resp. transmissions) for the same pair of UE(s).
· FFS: value range of N
R1-2310344 Summary #3 on Measurements and reporting for SL positioning Moderator (vivo)
From Friday session
Agreement
For the indicated number N of different SL PRS receptions (resp. transmissions) associated with the same SL PRS transmission (resp. reception), the value range of N is {2, 3, 4}.
Agreement
The TP in section 8.3 of R1-2310344 is endorsed for TS38.215 clause 5.1.37.
R1-2308845 Remaining issues for resource allocation for SL positioning reference signal SL PRS Nokia, Nokia Shanghai Bell
R1-2308876 Maintenance of SL-PRS resource allocation Huawei, HiSilicon
R1-2308946 Discussion on resource allocation for SL PRS FUTUREWEI
R1-2308985 Remaining issues on resource allocation for SL positioning reference signal Spreadtrum Communications
R1-2309073 Remaining issues on resource allocation for SL positioning reference signal vivo
R1-2309197 Remaining issues on resource allocation for SL positioning Intel Corporation
R1-2309221 Maintenance on resource allocation for SL positioning reference signal ZTE
R1-2309247 Remaining issues on resource allocation for SL positioning reference signal LG Electronics
R1-2309288 Remaining issues on resource allocation for SL positioning reference signal NEC
R1-2309374 Maintenance on Resource Allocation for SL Positioning Reference Signal Samsung
R1-2309457 Remaining details on resource allocation for SL positioning reference signal xiaomi
R1-2309525 Maintenance on resource allocation for SL positioning reference signal CATT, CICTCI
R1-2309540 Remaining issues on Resource allocation for SL PRS ASUSTeK
R1-2309550 Remaining issues on resource allocation for SL PRS China Telecom
R1-2309593 Remaining issues on resource allocation for SL positioning reference signal OPPO
R1-2309670 Maintenance on resource allocation for SL positioning reference signal CMCC
R1-2309782 Discussion on SL positioning resource allocation TOYOTA InfoTechnology Center
R1-2309789 Remaining Issues on Resource Allocation for SL-PRS Panasonic
R1-2309797 Remaining issues of SL PRS resource allocation InterDigital, Inc.
R1-2309832 On Resource allocation for SL positioning reference signal Apple
R1-2309874 Remaining Issues on Resource Allocation for Sidelink Positioning Continental Automotive
R1-2309882 Remaining issues on resource allocation for SL positioning reference signal Sharp
R1-2309905 Remaining Issues on resource allocation for SL positioning Sony
R1-2309947 Remaining aspects for SL Positioning Resource Allocation Lenovo
R1-2310140 Maintenance for SL PRS Resource Allocation Qualcomm Incorporated
R1-2310197 Remaining issues on resource allocation for SL positioning reference signal Ericsson
R1-2310241 Discussions on resource allocation for sidelink positioning ITL
R1-2310396 Moderator Summary #0 on resource allocation for SL PRS Moderator (Qualcomm)
From Monday session
Agreement
In scheme 1, with regards to distinguishing between DCI format 3_0 and 3_2:
Agreement
Sidelink PRS Received Signal Strength Indicator (SL PRS-RSSI) is defined as the linear average of the total received power (in [W]) observed in:
Agreement
The working assumption is confirmed with the following revision with regards to the number of padding bits:
· the padding bits, if any, are such that the size of the SCI format 2-D is the same as if the larger of SCI format 2-A or 2-B is embedded
|
Working assumption The number of bits in the embedded SCI format field of SCI format 2-D is 2 bits · If the “Embedded SCI format” field is set to 00, the SCI 2-A fields are included with necessary padding · If the “Embedded SCI format” field is set to 01, the SCI 2-B fields are included · If the “Embedded SCI format” field is set to 10, “size of SCI 2-B” number of reserved bits are included · If the “Embedded SCI format” field is set to 11, “size of SCI 2-B” number of reserved bits are included · Note: the size of SCI format 2-D is the same regardless of the value of the embedded SCI format field |
Agreement
In Scheme 2, with regards to the SCI-based triggering of SL-PRS, the following WA is confirmed:
|
Working assumption In Scheme 2, with regards to the triggering of SL-PRS, for the SCI-based triggering, the SL-PRS request, in either SCI-1B or SCI-2D, is an explicit field · If (pre-)configured per resource pool, then 1 bit is used, otherwise, it is 0 bits |
Agreement
|
[ If the '[SL PRS request]' field in the SCI associated with the received SL PRS is set to 1 then the UE shall report this request for SL PRS transmission to higher layers.] |
Conclusion
In scheme 1, with regards to an explicit indication of SL-PRS specific information in DCI format 3_0:
· Indication of SL-PRS specific information is not explicitly included in DCI
Agreement
With regards to the bitwidth of the field “Resource ID indication” when the value of the higher layer parameter sl-MaxNumPerReserveSL-PRS is configured to 3:
· Ceil(2*log2(Number of SL-PRS resources in (pre-)configuration)) bits should be used
Further discuss at TP for the above at RAN1#114bis.
Conclusion
In a dedicated resource pool, with regards to the PSCCH, do not introduce additional values for the subchannel (pre-)configuration.
Agreement
The following TP is endorsed for clause 16.4A of TS 38.213:
· Reason for change: to provide information regarding the starting PRB of PSCCH.
· Summary of change: include the information that the PSCCH starts from the lowest PRB of the sub-channel determined according to the index of the associated SL PRS resource
· The consequence if not approved is: the UE will not be able to determine which resource to use for PSCCH transmission
|
---------------------------- Start of Text Proposal for TS 38.213 ----------------------------- < Unchanged parts are omitted > 16.4A UE procedure for transmitting PSCCH in dedicated resource pool for SL PRS For a resource pool dedicated for SL PRS transmissions, a UE can be provided a number of symbols in the resource pool, by sl-TimeResourcePSCCH, starting from a second symbol that is available for SL transmissions in a slot, and a number of PRBs in the resource pool, by sl-FreqResourcePSCCH, starting from the lowest PRB of the sub-channel determined according to the index of the associated SL PRS resource for a PSCCH transmission with a SCI format 1-B. A UE that transmits a PSCCH with SCI format 1-B using SL PRS resource allocation scheme 2 [6, TS 38.214] sets < Unchanged parts are omitted > ---------------------------- End of Text Proposal for TS 38.213 ----------------------------- |
Agreement
Confirm the working assumption related to the TB size determination from RAN1 #114, and endorse the following TP:
|
Reason for change: |
Corrections on TBS in a shared resource pool |
|
|
|
|
Summary of change: |
In clause 8.1.3.2 of TS
38.214, complement the value of |
|
|
|
|
Consequences if not approved: |
The TBS procedure in a shared resoruce pool is incomplete. |
|
----------------------------------------- Start of text proposal to TS 38.214 v18.0.0------------------------------------------- 8.1.3.2 Transport block size determination <<< UNCHANGED PARTS OMITTED >>> · The UE shall first determine the number of REs (NRE) within the slot. - A UE first
determines the number of REs allocated for PSSCH within a PRB ( - - - - - - <<< UNCHANGED PARTS OMITTED >>> ----------------------------------------- End of text proposal to TS 38.214 v18.0.0------------------------------------------- |
Conclusion
For a dedicated resource pool, no more discussion on potential restriction by SL PRS-CBR and priority for the following SL PRS transmission parameters:
· Maximum Number of SL PRS resources in a slot
· Maximum comb-size of a SL PRS resource in a slot
· Maximum Number of OFDM symbols of a SL PRS resource in a slot
Agreement
With regards to the dedicated resource pool for positioning, suggest to the editors to align the terminology used as:
Conclusion
From RAN1 perspective, there is no need to introduce an association between a dedicated resource pool for positioning and a shared resource pool, or between a dedicated resource pool for positioning and a sidelink communication resource pool.
R1-2310414 Moderator Summary #1 on resource allocation for SL PRS Moderator (Qualcomm)
From Wednesday session
Agreement
Working assumption
Endorse the following TP for clause 8.2.4.2 of TS 38.214:
|
---------------------------- Start of Text Proposal for TS 38.214 ----------------------------- < Unchanged parts are omitted > 8.2.4.2 UE procedure for determining slots and SL PRS resource(s) associated with an SCI format 1-B in a dedicated resource pool The set of slots and SL PRS resources for SL PRS transmission is determined by the PSCCH containing the associated SCI format 1-B, and fields '[SL-PRS resource ID (s))', '[Time resource assignment]' of the associated SCI format 1-B as described below. The set of slots is determined as in clause 8.1.5, with the following modifications: - "SCI format 1-A" is replaced by "SCI format 1-B", - [ potential parameter name changes]. The
first SL PRS resource is determined according to the sub-channel used for the
PSCCH transmission containing the associated SCI format 1-B The second SL-PRS and third SL PRS resource, if reserved by SCI format 1-B, are determined from " Resource ID indication" which is equal to a PRS Resource ID value (PRIV) where, If [sl-MaxNumPerReserve] is 2 then
If [sl-MaxNumPerReserve] is 3 then
where ·
- ·
- ·
-
---------------------------- End of Text Proposal for TS 38.214 ----------------------------- < Unchanged parts are omitted > |
Agreement
For activation and deactivation of configured grant type 2 for SL PRS for DCI 3-2, use a dedicated field of size 1 bit.
From RAN1 perspective, whether to support or not reporting of CBR measurements to LMF or another UE, is left up to other WGs.
Agreement
With regards to the shared resource pool for positioning, suggest to the editors to align the terminology used as:
· “shared SL PRS resource pool” defined in 38.214 as shown below:
A sidelink resource pool which can be used for transmission of both SL PRS and PSSCH will be referred to as shared SL PRS resource pool.
Agreement
Endorse the TP below for clause 8.5.2.3 of TS 38.214
|
Reason for change: |
Corrections on description associated with SCI format 2-D in a shared resource pool for the CSI reference resource definition |
|
|
|
|
Summary of change: |
In clause 8.5.2.3 of TS 38.214, SCI format 2-D is captured. |
|
|
|
|
Consequences if not approved: |
The description associated with SCI format 2-D in CSI reference resource definition is missing |
|
8.5.2.3 CSI reference resource definition <<< UNCHANGED PARTS OMITTED >>> If configured to report CQI index and RI index, in the CSI reference resource, the UE shall assume the following for the purpose of deriving the CQI index and RI index: · - The reference resource uses the CP length and subcarrier spacing configured for the SL BWP. · - Redundancy Version 0. · - PSCCH occupies 2 OFDM symbols. · - The number of PSSCH and DM-RS symbols is equal to sl-LengthSymbols‒2. · - Assume no REs allocated for sidelink CSI-RS. · - Assume
no REs allocated SCI format 2-A, SCI format 2-B, <<< UNCHANGED PARTS OMITTED >>> ----------------------------------------- End of text proposal to TS 38.214 v18.0.0------------------------------------------- |
R1-2310483 Moderator Summary #2 on resource allocation for SL PRS Moderator (Qualcomm)
From Thursday session
Agreement
Step 5 for the resource selection procedure in Section 8.2.4.2 of 38.214 is modified as follows:
-
In
step 5, the second condition is modified as follows: for
any periodicity value allowed by the higher layer parameter sl-ResourceReservePeriodList
and any
SL PRS resource ID in the set of SL PRS resource ID(s) provided by the higher
layer, and a hypothetical SCI format
1-B
received in slot 
with 'Resource
reservation period' field set to that periodicity value and indicating that SL-PRS resource ID, condition c in step 6
would be met.
R1-2310601 Moderator Summary #3 on resource allocation for SL PRS Moderator (Qualcomm)
From Friday session
Agreement
Confirm the following Working Assumption made in RAN1#114bis:
|
Endorse the following TP for clause 8.2.4.2 of TS 38.214:
|
R1-2308877 Maintenance of CPP Huawei, HiSilicon
R1-2308955 Remaining issues on NR DL and UL carrier phase positioning Nokia, Nokia Shanghai Bell
R1-2308986 Remaining issues on NR DL and UL carrier phase positioning Spreadtrum Communications
R1-2309074 Remaining issues on carrier phase positioning vivo
R1-2309198 Remaining details on NR DL and UL Carrier Phase Positioning Intel Corporation
R1-2309222 Maintenance on carrier phase positioning ZTE
R1-2309326 Remaining issues on carrier phase positioning in NR LG Electronics
R1-2309375 Maintenance on NR DL and UL Carrier Phase Positioning Samsung
R1-2309458 Remaining issues on NR DL and UL carrier phase positioning xiaomi
R1-2309526 Maintenance on NR DL and UL carrier phase positioning CATT
R1-2309575 Remaining Issues of NR carrier phase positioning OPPO
R1-2309671 Maintenance on carrier phase positioning CMCC
R1-2309798 Remaining issues for positioning based on NR carrier phase measurement InterDigital, Inc.
R1-2309833 On NR DL and UL carrier phase positioning Apple
R1-2309938 Discussions on NR DL and UL carrier phase positioning Ruijie Network Co. Ltd
R1-2309948 DL/UL CPP Maintenance Discussion Lenovo
R1-2310033 Remaining issues on NR DL and UL carrier phase positioning NTT DOCOMO, INC.
R1-2310090 Maintenance for carrier phase positioning MediaTek Korea Inc.
R1-2310141 Maintenance for NR Carrier Phase Positioning Qualcomm Incorporated
R1-2310198 Remaining issues on NR DL and UL carrier phase positioning Ericsson
R1-2310284 FL Summary #1 for maintenance on NR DL and UL carrier phase positioning Moderator (CATT)
From Tuesday session
Agreement
A UE, which has the capability to support CPP in RRC_INACTIVE/RRC_IDLE state, should measure the DL PRS from the whole DL PFL, i.e., not limited to its initial DL BWP. The RF frequency associated with the DL RSCP/RSCPD when UE is in RRC_INACTIVE/RRC_IDLE state can be defined in the same way as a UE in RRC_CONNECTED state.
Agreement
For the timestamp associated with a reported UL RSCP measurement, NR-TimeStamp, with the granularity of a slot, currently defined in TS 38.455, can be reused as the timestamp.
· The TRP may optionally provide an OFDM symbol index in the timestamp.
· Note: It is up to RAN2/RAN3 how to signal the timestamp
Conclusion
No further discussion in RAN1 regarding the definition of per path RSCPD in Rel-18.
· Note: This conclusion does not impact the existing definition of the RSCP.
Conclusion
From RAN1’s perspective, there will be no further discussion on the four options that were agreed to consider in the following agreement made in RAN1#112bis-e.
|
Agreement To support NR carrier phase positioning, further consider the following options: · Option 1: Support a UE/TRP to report the carrier phase measurements of more than one frequency within a PFL/carrier to LMF o NOTE: the frequency can be the carrier frequency or the frequency of a subcarrier o FFS: the details of reporting, e.g., the maximum number of reported frequencies within a PFL/ carrier · Option 2: Introduce and report a new type of UE/TRP measurement based on carrier phase differentials across multiple subcarriers within a PFL/carrier o NOTE: carrier phase differentials across multiple subcarriers within a carrier can be related to time of arrival · Option 3: Support a UE/TRP to optionally report an estimated integer ambiguity and/or search range of the integer ambiguity to LMF · Option 4: Support LMF to provide the expected integer ambiguity range at least for UE-based NR CPP in the positioning assistance data. |
Agreement
Subject to UE’s capability, if a UE Rx-Tx
time difference/DL RSTD measurement is obtained with 
(=2, 4) samples, as defined in TS 38.133, the UE Rx-Tx time
difference/DL RSTD measurement can be associated with (i.e., reported together
with) up to RSCP/RSCPD measurements.
· A single RSCP/RSCPD measurement is obtained within one sample
· Each RSCP/RSCPD measurement has its own timestamp.
· Note: It is up to RAN2 on how to define signalling support for the reporting of the timestamps of the RSCP/RSCPD measurements.
Conclusion
No further discussion in RAN1 regarding the support of standalone reporting of NR carrier phase measurements in Rel-18.
Agreement
Endorse the following TP regarding the reporting of the phase quality indication for the RSCP/RSCPD measurements in Clause 5.1.6.5 of TS 38.214.
|
Reason for change: |
The specification does not capture the following agreement made in RAN1#114 regarding to the report of the quality indication associated with DL RSCP/RSCPD measurement. Agreement Support UE/TRP to report the phase quality indication for the RSCP/RSCPD measurements. The phase quality indication includes the following fields:
|
|
Summary of change: |
Add the report of the quality indication associated with DL RSCP/RSCPD measurement according to the agreement made in RAN1#114. |
|
Consequences if not approved: |
Specification is not aligned with RAN1’s agreement and incomplete |
|
5.1.6.5 PRS reception procedure ===================== Unchanged parts omitted ====================== The UE may be configured with [higher layer parameter] which contains DL carrier phase measurements performed by a positioning reference unit (PRU) [20, TS 38.305] along with the location information of the PRU. The UE may be configured to report quality metrics [higher layer parameter] corresponding to the DL RSCP and RSCPD measurements which include the following fields [17, TS 37.355]: · - [phase quality index] which provides the uncertainty of the measurement · - [phase quality resolution] which specifies the resolution levels used in the [phase quality index] field. ===================== Unchanged parts omitted ====================== |
Agreement
The timing windows, which were agreed to be introduced for simultaneous PRS measurements in Rel-18, are applicable for UE in RRC_CONNECTED, RRC_INACTIVE, and RRC_IDLE states.
Note: no RAN1 specification impact.
Agreement
The timing windows, which were agreed to be introduced for simultaneous SRS for positioning transmission in Rel-18, are applicable for UE in RRC_CONNECTED and RRC_INACTIVE states.
Note: no RAN1 specification impact.
R1-2310285 FL Summary #2 for maintenance on NR DL and UL carrier phase positioning Moderator (CATT)
From Thursday session
Agreement
Endorse the TP in Section 9.1 of R1-2310285 for Clause 5.1.6.5 of TS 38.214.
Agreement
· Adopt the following changes to the previous agreement made in RAN1#114:
|
Agreement When an LMF requests the UEs, including target UE and PRU(s), to perform measurements on indicated DL PRS resource set(s) occurring within indicated time window(s) · The duration of a time window can be configured as follows: o {1, 2, 4, 6, 8, 12, 16} slots. · the number of the time windows can be: o {1, 2} o · the number of the indicated DL PRS resource set(s) per TRP within a time window can be {1, 2}: o DL PRS resource sets across all TRPs are in one DL PFL § FFS: For PRS bandwidth aggregation, an indicated DL PRS resource set refers to a combination of linked PRS resource sets o The number of the indicated DL PRS resource set(s) for all TRPs should be the same · Note: Different PRS resource sets and/or PFLs can be associated with different time windows · Note: the signaling design for the indication of the DL PRS resource sets in the time windows is up to RAN2/RAN3. |
Agreement
Only the carrier phase measurements (i.e., DL/UL RSCP, DL RSCPD) of the first path are supported in Rel-18.
Agreement
R1-2310286 FL Summary #3 for maintenance on NR DL and UL carrier phase positioning Moderator (CATT)
From Friday session
Agreement
· Adopt the following changes to the previous agreement made in RAN1#114bis:
|
Agreement The DL PRS resource used to obtain a DL RSCP measurement is either the same DL PRS resource used to obtain the associated UE Rx-Tx time difference measurement, or one of the DL PRS resources used to obtain the associated UE Rx-Tx time difference measurement. - Note 1: a DL RSCP measurement is obtained by measuring a single DL PRS resource from a TRP. - Note 2: It has no RAN1 impact. It is up to RAN2 on how the DL PRS resource IDs of DL RSCP measurements are identified/reported. |
Agreement
The pair of the DL PRS resources used to obtain a DL RSCPD measurement are either the same as the pair of DL PRS resources used to obtain the associated DL RSTD measurement, or one of the pairs of DL PRS resources used to obtain the associated DL RSTD measurement.
· Note 1: It has no RAN1 impact. It is up to RAN2 on how the DL PRS resource IDs of DL RSCPD measurements are identified/reported.
Agreement
From RAN1’s perspective, the granularity with ReportingGranularityfactor k={-1, -2} for the reporting of DL/UL timing measurements is applicable to all positioning methods.
Conclusion
No further discussion in RAN1 on how to address the impact of the phase delays on Tx/Rx RF chains in Rel-18.
· Note: The conclusion does not preclude further discussion of the phase delays in UE feature for NR CPP.
R1-2308878 Maintenance of LPHAP Huawei, HiSilicon
R1-2308956 Remaining issues on LPHAP Nokia, Nokia Shanghai Bell
R1-2309075 Remaining issues on low power high accuracy positioning vivo
R1-2309223 Maintenance on low power high accuracy positioning ZTE
R1-2309286 Remaining issues on Low Power High Accuracy Positioning NEC
R1-2309336 Discussion on Low Power High Accuracy Positioning Quectel
R1-2309376 Maintenance on Low Power High Accuracy Positioning Samsung
R1-2309527 Maintenance on low power high accuracy positioning CATT
R1-2309577 Remaining issue of low power high accuracy positioning OPPO
R1-2309672 Maintenance on low power high accuracy positioning CMCC
R1-2309799 Remaining issues on Low Power High Accuracy Positioning (LPHAP) techniques InterDigital, Inc.
R1-2309834 On Low Power High Accuracy Positioning Apple
R1-2309906 Remaining Issues on LPHAP Sony
R1-2310034 Remaining issues on low power high accuracy positioning NTT DOCOMO, INC.
R1-2310142 Maintenance on LPHAP Positioning Qualcomm Incorporated
R1-2310199 Remaining issues on Low Power High Accuracy Positioning Ericsson
R1-2310318 Summary #1 for low power high accuracy positioning Moderator (CMCC)
From Tuesday session
Agreement
Endorse the following TP for TS 38.214 Clause 6.2.1.4.
· Reason for change: When UE cannot accurately measure the configured DL RS in SRS-SpatialRelationInfoPos, the UE sounding procedures in Rel-17 when SRS-PosRRC-InactiveConfig-ValidityArea is not provided, and in Rel-18 when SRS-PosRRC-InactiveConfig-ValidityArea is configured in RRC_INACTIVE state is not the same.
· Summary of change: Distinguish different UE sounding procedures in Rel-17 when SRS-PosRRC-InactiveConfig-ValidityArea is not provided, and in Rel-18 when SRS-PosRRC-InactiveConfig-ValidityArea is configured in RRC_INACTIVE state, when UE cannot accurately measure the configured DL RS in SRS-SpatialRelationInfoPos.
· Consequences if not approved: The UE behaviour in RRC_INACTIVE states when the configured DL RS in SRS-SpatialRelationInfoPos cannot be accurately measured may be ambiguous.
|
<Unchanged parts are omitted> If the UE in RRC_INACTIVE mode is not provided [SRS-PosRRC-InactiveConfig-ValidityArea], and determines that the UE is not able to accurately measure the configured DL RS in SRS-SpatialRelationInfoPos for a SRS resource for positioning where the DL RS is semi-persistent or periodic, the UE stops transmission of the SRS resource for positioning. <Unchanged parts are omitted> |
Conclusion
Muting option 1 is not applicable when the periodicity of DL PRS is larger than 10240 ms.
Final summary in R1-2310319.
R1-2308879 Maintenance of positioning with BW aggregation Huawei, HiSilicon, China Telecom, China Unicom
R1-2308957 Remaining issues on bandwidth aggregation for positioning measurements Nokia, Nokia Shanghai Bell
R1-2308987 Remaining issues on bandwidth aggregation for positioning measurements Spreadtrum Communications
R1-2309076 Remaining issues on bandwidth aggregation for positioning measurements vivo
R1-2309199 Remaining issues on Bandwidth Aggregation for Positioning Intel Corporation
R1-2309224 Maintenance on BW aggregation for positioning ZTE
R1-2309327 Remaining issues on Bandwidth aggregation for positioning measurements LG Electronics
R1-2309377 Maintenance on Bandwidth Aggregation for Positioning Measurements Samsung
R1-2309459 Remaining issues on bandwidth aggregation for positioning measurement xiaomi
R1-2309528 Maintenance on bandwidth aggregation for positioning measurements CATT
R1-2309576 Remaining Issues of bandwidth aggregation for positioning measurement OPPO
R1-2309673 Maintenance on BW aggregation for positioning measurements CMCC
R1-2309800 Remaining issues on bandwidth aggregation for positioning measurements InterDigital, Inc.
R1-2309835 On Bandwidth aggregation for positioning measurements Apple
R1-2310035 Remaining issues on bandwidth aggregation for positioning measurements NTT DOCOMO, INC.
R1-2310143 Maintenance on Bandwidth aggregation for Positioning Qualcomm Incorporated
R1-2310200 Remaining issues on Bandwidth aggregation for positioning measurements Ericsson
R1-2309227 Summary #1 for BW aggregation positioning Moderator (ZTE)
From Tuesday session
Agreement
Configuring up to two PFL combinations is supported (e.g. PFL1 aggregated with PFL2 and PFL3 aggregated with PFL4).
· Send an LS to RAN4 (CC to RAN2 and RAN3) to inform them with the above agreement and specify corre-sponding requirements.
· Note: more than one combinations are measured in TDMed manner.
Comeback for draft LS
R1-2310477 Draft LS on PRS bandwidth aggregation Moderator (ZTE)
Thursday decision: The draft LS to RAN4 in R1-2310477 is endorsed. Final LS is approved in R1-2310478.
Agreement
Endorse the TP in section 3.2 of R1-2309227 for TS 38.214 clause 6.2.1.4.
Agreement
Endorse TP 6.2-2 in section 6.2.2 of R1-2309227 for TS 38.214 clause 5.1.6.5.
Agreement
Endorse TP 5.1-1 in section 5.1-1 of R1-2309227 for TS 38.214 clause 5.1.6.5.
Agreement
For positioning SRS bandwidth aggregation, introduce a new RRC signaling to indicate whether to enable Rel-17 single DCI-triggering SRS resource sets across the linked carriers.
Agreement
Confirm the following WA:
|
Working assumption For semi-persistent positioning SRS for bandwidth aggregation, a single MAC CE can activate or deactivate: · SRS resource set(s) in one or two or three of three aggregated carriers · SRS resource set(s) in one or two of two aggregated carriers. Note: the single spatial relation is indicated by the MAC CE for each of two or three aggregated SRS resources. |
R1-2309228 Summary #2 for BW aggregation positioning Moderator (ZTE)
From Thursday session
Agreement
Endorse the TP in section 8.1.1 of R1-2309228 for TS 38.214 clause 5.1.6.5 and 6.1.2.4
Agreement
With regards to the bandwidth aggregation measurement for positioning, suggest to the editor of TS38.214 to align the terminology between “joint measurement” and “aggregated measurement” by using only “aggregated measurement”.
Agreement
Endorse the TP in section 9.1.1 of R1-2309228 for TS 38.213 clause 7.3.1.
Agreement
When the LMF requests aggregated measurements, the following existing requested fields can also be applicable:
Final summary in R1-2309229.
R1-2308880 Maintenance of RedCap positioning Huawei, HiSilicon
R1-2308943 On remaining open issues in RedCap UE positioning FUTUREWEI
R1-2308958 Remaining issues on Positioning for RedCap UEs Nokia, Nokia Shanghai Bell
R1-2308988 Remaining issues on positioning for RedCap UEs Spreadtrum Communications
R1-2309077 Remaining issues on positioning for RedCap UEs vivo
R1-2309200 Remaining issues on Positioning for RedCap UEs Intel Corporation
R1-2309225 Maintenance on Positioning for RedCap UEs ZTE
R1-2309289 Remaining issues of positioning for RedCap UEs NEC
R1-2309328 Remaining issues on positioning support for RedCap UEs LG Electronics
R1-2309378 Maintenance on Positioning for RedCap UEs Samsung
R1-2309529 Maintenance on positioning for RedCap UEs CATT
R1-2309578 Remaining issue of positioning for RedCap UEs OPPO
R1-2309674 Maintenance on RedCap UE positioning CMCC
R1-2309801 Remaining issues on positioning for RedCap UEs InterDigital, Inc.
R1-2309836 On Positioning for RedCap UEs Apple
R1-2309907 Remaining Issues on Positioning for RedCap UEs Sony
R1-2310036 Remaining issues on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2310091 Maintenance for positioning for RedCap UE MediaTek Korea Inc.
R1-2310144 Maintenance on Positioning for Reduced Capabilities UEs Qualcomm Incorporated
R1-2310201 Remaining issues on Positioning for RedCap UEs Ericsson
R1-2310429 Feature Lead summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
From Tuesday session
Agreement
For SRS Tx hopping, the configuration parameters values are:
Working assumption
For the SRS for positioning with Tx hopping wrapping pattern, the starting frequency for each symbol of the wrapped staircase pattern is configured by:
a new offset nFH
is added to the existing equation for the starting frequency 
, where
Where:
- 
is the
frequency hop index of the initial hop.
- FFS whether this is signaled as a new parameter.
- 
is the
SRS hop transmission counter in time domain
-
is the
configured number of hops
-
is the
configured hop bandwidth, in number of RBs
-
is the
configured common overlap between two hops, in number of RB(s).
In the definition
of the starting PRB of the SRS 
, the
starting PRB is configured as:
•
In k0, nshift is replaced by startingPRBfirsthop
- n0*( –)* 
R1-2310430 Feature Lead summary #2 for Positioning for RedCap UEs Moderator (Ericsson)
From Thursday session
Agreement
The UTW configuration applies to all SRS for positioning with Tx hopping configurations in the serving cell.
Agreement
The agreement below is updated by removing the bracket on “or outside” and adding one note.
Agreement
For RedCap UEs positioning transmitting the UL SRS with frequency hopping, regarding the collisions between other UL and DL signals/channels and the UL SRS with frequency hopping, support both of the following options
-
Option 1: UL time window where the UE is
not expected to [receive/]transmit
other signals/channels and is only expected to transmit FH SRS for positioning.
- FFS details of an UL time window
- Note: it implies that UE drops the transmission of other signals/channels and transmits SRS for positioning
-
Option 2: new collision rules between the
UL SRS with frequency hopping and other UL and DL signals/channels/. Option 2
can apply without [or outside] UL
time window (i.e. option 1)
- FFS: details on the collision rules
Note: it is understood that option 2 is a component of the feature for UL SRS Tx hopping (FG 41-5-2), and option 1 is a separate feature group.
Note: UE is not expected to be configured with a SRS for positioning hopping cycle partially overlapping with UTW.
Agreement
For DL PRS Rx hopping, support the LMF to include an explicit request for DL PRS Rx hopping measurements and reporting in the location request signaling.
The location information request can also optionally include the total bandwidth of all hops.
Agreement
With regards to the configuration of the UTW:
Agreement
For the collision rules of the SRS with Tx hopping (option2)
Agreement
TP 2.2-1 in section 2.2.1 of R1-2310430 is endorsed for TS 38.214 clause 5.1.6.5.
R1-2310431 Feature Lead summary #3 for Positioning for RedCap UEs Moderator (Ericsson)
From Friday session
Agreement
The working assumption is revised as follow:
Working assumption
For the SRS for positioning with Tx hopping wrapping pattern, the starting frequency for each symbol of the wrapped staircase pattern is configured by:
a new offset nFH
is added to the existing equation for the starting frequency , where
Where: (down-select at RAN1#115)
-alt1: is the
frequency hop index of the initial hop (new configured parameter)
-alt2: 
n Note:
The reference point for starting PRB of the first hop 
and nshift
is defined as lowest RB provided by the agreed configuration that may include
SCS, CP size and bandwidth (position and size)
- 
is the starting PRB of the first hop
- In k0,
nshift is replaced by 
- is the
SRS hop transmission counter in time domain
- is the
configured number of hops
- is the
configured hop bandwidth, in number of RBs
- is the
configured common overlap between two hops, in number of RB(s).
Agreement
SRS for positioning with Tx hopping can be configured to be periodic, aperiodic or semi-persistent.
R1-2312504 Session notes for 8.3 (Maintenance on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
Friday decision: The session notes are endorsed and contents reflected below.
[115-R18-Pos] – Debdeep (Intel)
Email discussion on NR positioning
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2311141 Higher layer parameters for Rel-18 Expanded and Improved NR Positioning Rapporteur (Intel Corporation)
R1-2312690 RAN1 agreements for Rel-18 WI on Expanded and Improved NR Positioning Rapporteur (Intel Corporation)
From AI 5
R1-2310787 LS on request for clarifications on RedCap positioning, carrier phase positioning, and bandwidth aggregation for positioning RAN2, Nokia
Decision: To be handled in agenda item 8.3 - To be moderated by Hyunsu (Nokia).
R1-2312380 Moderator Summary #1 on Reply LS on request for clarifications on RedCap positioning, carrier phase positioning, and bandwidth aggregation for positioning Moderator (Nokia)
From Tuesday session
Answer for Q2 and Q3
|
Q2) For RedCap UEs to support SRS for positioning frequency hopping by using a BWP configuration separate from the existing BWP configuration, is the separate BWP configuration inside each existing data BWP or outside any data BWP? Q3) Please confirm if UE/gNB measurement reported with frequency hopping applies to RSTD, RSRP, RTOA, UE Rx-Tx time difference and gNB Rx-Tx time difference measurements for DL-TDOA, UL-TDOA and Multi-RTT positioning methods. |
· From RAN1 perspective, the separate BWP configuration is outside any data BWP configuration.
· Yes, RAN1 confirms RAN2 understanding. Also, the UE/gNB measurement reported with frequency hopping applies to RSRPP measurement.
Answer for Q1)
|
Q1) For DL PRS Rx frequency hopping, does LMF have to signal the hopping pattern configuration to the UE or not? What about the same for UL SRS Tx frequency hopping? |
LMF does not need to provide the UE with the hopping pattern configuration for DL PRS Rx frequency hopping or UL SRS Tx hopping.
· For DL PRS Rx frequency hopping, LMF sends an explicit request for DL PRS Rx hopping measurement and reporting, and optionally include the total bandwidth of all hops in the location request signaling based on the following agreement.
|
Agreement For DL PRS Rx hopping, support the LMF to include an explicit request for DL PRS Rx hopping measurements and reporting in the location request signaling. The location information request can also optionally include the total bandwidth of all hops. |
· For UL SRS frequency hopping, a serving gNB provides the UE with a SRS Tx frequency hopping pattern.
Answer for Q4 and Q5
|
Q4) Has RAN1 discussed the interaction between carrier phase positioning and bandwidth aggregation for positioning? When bandwidth aggregation is used involving 2 or 3 positioning frequency layers (PFL), does the UE report the carrier phase measurement for each PFL or only one PFL? Q5) Is the simultaneous measurement on same DL PRS by a target UE and a PRU applies only for carrier phase measurements (RSCP/RSCPD) or applies also to the legacy measurement along which the carrier phase measurements are reported? Please clarify if simultaneous measurement applies to all legacy measurements (e.g., timing, power measurements) or not. |
· No, the interaction of carrier phase positioning and bandwidth aggregation for positioning has not been discussed. The UE reports the carrier phase measurement for only one PFL.
· The simultaneous measurement on same DL PRS by a target UE and a PRU also applies to all legacy measurements.
Answer for Q6 and Q7
|
Q6) For simultaneous measurement on same DL PRS by a target UE and a PRU, is multiple instances of time window configurations need to be signalled to the target UE and PRU or is the set of time window configuration parameters results in multiple time domain windows for the measurement? RAN2 would like additional clarification on need for multiple time windows. Q7) For simultaneous transmission of UL SRS from a target UE and a PRU, is there a need for gNB to indicate the time window(s) directly to UE? |
· Each time window configuration optionally includes a periodicity, which results in multiple instances of the time window. Up to 2 different window configurations can be provided.
· For Q7, there is no such need.
Answer for Q9
|
Q9) Are carrier phase measurements reported by UE for additional paths also or only for the first path of the associated legacy timing measurement? |
· UE reports carrier phase measurements only for the first path.
Answers for Q11, Q12, and Q13
· UE Rx-Tx time difference measurement in RRC_IDLE is not supported using bandwidth aggregation or without using bandwidth aggregation.
· The condition on “The same number of PRS resource sets and resources for a TRP” is not needed.
· The aggregated reference RSTD means a reference RSTD, where the reference RSTD is derived from aggregated DL PRS Resources. RAN1 have not discussed the aggregated reference RSTD reporting requirement, which is up to RAN4.
R1-2312432 Moderator Summary #2 on Reply LS on request for clarifications on RedCap positioning, carrier phase positioning, and bandwidth aggregation for positioning Moderator (Nokia)
From Wednesday session
Agreement
|
Q8) For UE-based carrier phase positioning, RAN1 agreement says the LMF forwards the DL carrier phase measurement reported by a PRU, with additional information of the same PRU to a target UE in the positioning assistance data. Regarding the forwarded measurement, does the LMF forward only the carrier phase measurement or also the legacy measurement associated with the carrier phase measurement? Also, how often does the LMF have to forward the positioning assistance data containing PRU measurement (and additional information of the same PRU) to the target UE i.e., is this supposed to be a periodic provisioning of assistance data from LMF to target UE? Can the UE send a request to the LMF to initiate the periodic provisioning of assistance data? |
The LMF can forward the carrier phase measurements together with the legacy measurement associated with the carrier phase measurement.
· Note1: there is no consensus in RAN1 that the LMF can forward UE Rx-Tx time difference measurement.
· Note2: carrier phase measurements include both RSCP and RSCPD
Both one time (aperiodic) and periodic provision of PRU carrier phase measurements should be supported, which could be requested by the UE.
Answer for Q10
|
Q10) For PRS bandwidth aggregation should the LMF indicate to the UE that one TRP can have multiple pairs of aggregated PFLs i.e., multiple combinations of linked PFLs e.g., 2+2 and other combinations? Also, can the same PFL(s) be configured in different combinations of linked PFLs? |
For the 1st question, Yes, up to two PFL combinations can be supported from the following agreement.
|
Agreement Configuring up to two PFL combinations is supported (e.g. PFL1 aggregated with PFL2 and PFL3 aggregated with PFL4). · Send an LS to RAN4 (CC to RAN2 and RAN3) to inform them with the above agreement and specify corre-sponding requirements. · Note: more than one combinations are measured in TDMed manner |
For the 2nd question,
· Yes, RAN1 understanding is that the same PFL can be configured in different combinations of the linked PFLs. For example, different PRS resource sets in the same PFL can be configured in different combinations of the linked PFLs.
o Note: From RAN1 perspective, it is unnecessary to configure the same PRS resource set in different combinations of linked PFLs.
R1-2312433 Draft Reply LS on request for clarifications on RedCap positioning, carrier phase positioning, and bandwidth aggregation for positioning Moderator (Nokia)
Decision: The draft LS reply to RAN2 in R1-2312433 is endorsed with the following correction:
· To: RAN2
· Cc: RAN3, RAN4
Final LS is approved in R1-2312434.
R1-2310815 Remaining issues for design of SL positioning reference signal SL PRS Nokia, Nokia Shanghai Bell
R1-2310836 Maintenance of SL-PRS Huawei, HiSilicon
R1-2311094 Remaining issues on SL positioning reference signal vivo
R1-2311163 Remaining issues on SL positioning reference signal Spreadtrum Communications
R1-2311240 Remaining issues on SL positioning reference signal OPPO
R1-2311339 Maintenance issues on SL positioning reference signal CATT, CICTCI
R1-2311402 Remaining details on SL positioning reference signal xiaomi
R1-2311430 Remaining issues on SL positioning reference signal NEC
R1-2311456 Maintenance on SL positioning reference signal ZTE
R1-2311559 Maintenance on sidelink positioning reference signal ASUSTeK
R1-2311595 Remaining issues on SL-PRS design and power control for SL-PRS InterDigital, Inc.
R1-2311682 Remaining Issues On SL positioning reference signal Apple
R1-2311747 Remaining issues on SL positioning reference signal Sharp
R1-2311841 Maintenance on SL Positioning Reference Signal Samsung
R1-2311932 Remaining issues on SL positioning reference signal Ruijie Network Co. Ltd
R1-2312033 Reference Signal Design for SL Positioning Qualcomm Incorporated
R1-2312092 Maintenance for SL-PRS design MediaTek Korea Inc.
R1-2312123 Remaining issues on SL positioning reference signal LG Electronics
R1-2312185 Remaining issues on SL positioning reference signal design Ericsson
R1-2312295 FL summary #1 on SL positioning reference signal Moderator (Intel Corporation)
From Tuesday session
Agreement
The TP below is endorsed for TS 38.214
|
Reason for change |
Correct the description for unique determination of a SL PRS resource in a slot of a shared SL PRS resource pool. |
|
Summary of change |
Section 8.2.4 in TS 38.214: 1. In clause 8.2.4 of TS 38.214, correct the description for unique determination of a SL PRS resource in a shared SL PRS resource pool. 2. Add reference to SCI format 1-A for indication of “frequency resource assignment” for a SL PRS resource in a slot of a shared SL PRS resource pool. |
|
Consequences if not approved |
Incorrect description for unique determination of a SL PRS resource in a slot of a shared SL PRS resource pool. |
|
Text proposal |
------------------------------ TP#1: TS 38.214 ----------------------------------- 8.2.4 SL PRS transmission procedure The following parameters for SL PRS transmission are associated with each SL PRS resource: · - [SL PRS resource ID] indicates an identity of a SL PRS resource. The SL PRS resource is identified by the SL PRS resource ID that is unique within a slot of a dedicated SL PRS resource pool. For a shared SL PRS resource pool, a SL PRS resource is uniquely identified by a combination of the SL PRS resource ID, a SL PRS frequency domain allocation within a slot indicated by “frequency resource assignment” field in the associated SCI format 1-A, and a starting symbol within the slot as determined by clause 8.2.4.1.1. · - [SL PRS comb offset and comb size] indicates a comb offset and a comb size of the SL PRS resource · - [Starting symbol and the number of SL PRS symbols] indicates the starting symbol index and the number of symbols of the SL PRS resource within a slot in a dedicated SL PRS resource pool. [number of SL PRS symbols] indicates the number of symbols of the SL PRS resource within a slot in a shared SL PRS resource pool. < Unchanged text omitted > |
Agreement
Endorse TP#2 in Section 6 of R1-2312295 for Section 8.4.1.6.3 of TS 38.211 to add “common” to description of resource blocks for mapping of SL PRS and to correct terminology for dedicated and shared SL PRS re-source pools.
Agreement
Endorse TP#3 in Section 6 of R1-2312295 for Section 16.2.3A of TS 38.213 to align terminology for shared SL PRS resource pool.
· Note: clause and TS in summary of change should be fixed by the editor.
Agreement
Endorse TP#4 in Section 6 of R1-2312295 for Clause 8 and Subclause 8.2.4.1.2 of TS 38.214 to reflect that the bandwidth of SL PRS in a dedicated SL PRS resource pool is same as the resource pool bandwidth in number of RBs.
Agreement
Endorse TP#5 and TP#6 in Section 6 of R1-2312295 to correctly reflect the resource mapping and UE behavior for multiplexing between SL PRS and each of PSSCH and PSFCH in a slot of a shared SL PRS resource pool:
· TP#5 for subclauses 8.3.1.5 and 8.4.1.1.2 of TS 38.211.
· TP#6 for subclause 8.2.4.1.1 of TS 38.214.
R1-2312296 FL summary #2 on SL positioning reference signal Moderator (Intel Corporation)
Presented in Thursday session.
Final summary in R1-2312297.
R1-2310816 Remaining issues for measurements and reporting for SL positioning Nokia, Nokia Shanghai Bell
R1-2310837 Maintenance of SL measurements Huawei, HiSilicon
R1-2311095 Remaining issues on measurements and reporting for SL positioning vivo
R1-2311142 Remaining issues on SL Positioning Measurements and Reporting Intel Corporation
R1-2311164 Remaining issues on measurements and reporting for SL positioning Spreadtrum Communications
R1-2311241 Remaining issues on measurements and reporting for SL positioning OPPO
R1-2311340 Maintenance issues on measurements and reporting for SL positioning CATT, CICTCI
R1-2311457 Maintenance on SL positioning measurements and reporting ZTE
R1-2311481 Maintenance on measurements and reporting for SL positioning CMCC
R1-2311596 Remaining issues on measurement and reporting for SL positioning InterDigital, Inc.
R1-2311683 Remaining Issues On Measurements and reporting for SL positioning Apple
R1-2311842 Maintenance on Measurements and Reporting for SL Positioning Samsung
R1-2311949 SL Pos. Measurement and Reporting Maintenance Lenovo
R1-2312034 Measurements and Reporting for SL Positioning Qualcomm Incorporated
R1-2312124 Remaining issues on measurements and reporting for SL positioning LG Electronics
R1-2312186 Remaining issues on measurements and reporting for SL positioning Ericsson
R1-2312416 Summary #1 on Measurements and reporting for SL positioning Moderator (vivo)
From Wednesday session
Agreement
Regarding the time stamp information in measurement report, support the following:
· For the timestamp of SFN and slot number, at least one of nr-PhysCellID, nr-ARFCN, nr-CellGlobalID is included.
· For the timestamp of DFN and slot number, the synchronization reference source indication ‘GNSS or UE’ can be optionally included.
Note: The number of SL-PRS symbols is not signalled in the SL positioning measurement report.
Agreement
Define the maximum number of additional paths for SL-RSTD, SL-RTOA and SL Rx – Tx time difference to be equal to 8. The maximum number of additional paths for SL-AoA is equal to 2.
Agreement
Update previous agreement on synchronization information exchange with the following modification:
|
To mitigate the impact of synchronization errors between anchor UEs for SL-PRS based measurement, the exchanged synchronization information of anchor UEs between a UE and LMF or another UE includes the following: · The synchronization source type (GNSS, gNB/eNB, and UE) of anchor UEs,
o If the synchronization source of an anchor UE is gNB/eNB, the anchor UE can further provide cell identity information
· The RTD between anchor UEs |
Agreement
The TP below is endorsed for TS38.214 clause 8.4.4.
|
Reason for change |
In current spec, UE may provide the ARP location information in assistance data for the ARP ID reported in the measurement report. However, those two reporting should be decoupled, for example, a UE can provide ARP location information in assistance data but do not report any ARP ID in measurement report. |
|
Summary of change |
Section 8.4.4 in TS 38.214: Decouple ARP ID report in measurement report and ARP location information provision in assistance data |
|
Consequences if not approved |
unnecessary association between the provision of ARP location information in assistance data and the reporting of ARP ID in measurement report. |
|
Text proposal |
8.4.4 SL PRS reception procedure The UE may
be configured, via [higher layer parameter(s)], to measure and report
one or more of the SL RSTD, SL Rx-Tx time difference, SL RTOA, SL AoA, SL
PRS-RSRP, and SL PRS-RSRPP measurements, for the first detected path and/or
additional detected paths. The UE may report an ARP ID associated with the
reported measurements. The UE may provide the ARP location information |
Agreement
The TP below is endorsed for TS38.214 clause 8.4.4.
|
Reason for change |
· Based on current agreements, the exchanged synchronization information of anchor UEs between a UE and LMF or another UE includes: (1) synchronization source type; (2) RTD between anchor UEs. The description in 38.214 is redundant. · Based on the description in TS38.214, it seems that UE may report synchronization source type and/or RTD via the same higher layer parameter, however, they should be associated with different higher layer parameters. |
|
Summary of change |
Section 8.4.4 in TS 38.214: · Change “The UE may report synchronization information synchronization source type and/or…” to “The UE may report synchronization source type and/or…” · Add separate higher layer parameter for ‘synchronization source type’. |
|
Consequences if not approved |
· Redundant specification. · Incorrect higher layer parameter association for synchronization source type and RTD. |
|
Text proposal |
< Unchanged text omitted > The
UE may report < Unchanged text omitted > |
Agreement
The TP below is endorsed for TS38.214 clause 8.2.4.
|
Reason for change |
1. In TS 38.214 section 8.2.4, the bracket around ‘SL PRSs of SL PRS resources’ should be addressed. 2. It has been agreed that SL PRS resource ID is ‘optional’ for the association information between the already transmitted SL PRSs of SL PRS resources and UE Tx ARP ID. But the agreement is not correctly captured in the current RAN1 specification. |
|
Summary of change |
Section 8.2.4 in TS 38.214: 1. Remove brackets around ‘SL PRSs of SL PRS resources’. 2. Capture ‘optional’ SL PRS resource ID included in the association information between the already transmitted SL PRS resource and UE Tx ARP ID.
|
|
Consequences if not approved |
1. Unclear specification for [SL PRSs of SL PRS resources] in TS38.214. 2. The agreement is not correctly captured for SL PRS resource ID. |
|
Text proposal |
< Unchanged text omitted > The
UE may report the association information between the already transmitted < Unchanged text omitted > |
Agreement
The TP below is endorsed for TS38.214 clause 8.4.4.
|
Reason for change |
SL PRS-RSRP measurement is not defined for the first detected path and/or additional paths, which is not correctly captured by the specification. |
|
Summary of change |
Section 8.4.4 in TS 38.214: Delete the association between the first detected path and/or additional detected paths and SL PRS-RSRP measurement. |
|
Consequences if not approved |
Incorrect description for the association between the first detected path and/or additional detected paths and SL PRS-RSRP measurement. |
|
Text proposal |
< Unchanged text omitted > The
UE may be configured, via [higher layer parameter(s)], to measure and
report one or more of the SL RSTD, SL Rx-Tx time difference, SL RTOA, SL AoA,
< Unchanged text omitted > |
R1-2312417 Summary #2 on Measurements and reporting for SL positioning Moderator (vivo)
From Thursday session
Agreement
For SL RTT, support LMF/UE to request with higher layer signaling the measuring UE to report the associated SL-PRS transmission timestamp.
· Up to RAN4 to determine conditions (if any) for reporting of the associated SL-PRS transmission timestamp.
Final summary in R1-2312418.
R1-2310817 Remaining issues for resource allocation for SL positioning reference signal SL PRS Nokia, Nokia Shanghai Bell
R1-2310838 Maintenance of SL-PRS resource allocation Huawei, HiSilicon
R1-2311096 Remaining issues on resource allocation for SL positioning reference signal vivo
R1-2312293 Remaining issues on resource allocation for SL positioning Intel Corporation (rev of R1-2311143)
R1-2311165 Remaining issues on resource allocation for SL positioning reference signal Spreadtrum Communications
R1-2311242 Remaining issues on resource allocation for SL positioning reference signal OPPO
R1-2311341 Maintenance issues on resource allocation for SL positioning reference signal CATT, CICTCI
R1-2311403 Remaining details on resource allocation for SL positioning reference signal xiaomi
R1-2311431 Remaining issues on resource allocation for SL positioning reference signal NEC
R1-2311458 Maintenance on resource allocation for SL positioning reference signal ZTE
R1-2311482 Maintenance on resource allocation for SL positioning reference signal CMCC
R1-2311544 Remaining issues on resource allocation for SL PRS China Telecom
R1-2311560 Maintenance on Resource allocation for SL PRS ASUSTeK
R1-2311597 Remaining issues on SL PRS resource allocation InterDigital, Inc.
R1-2311684 Remaining Issues On Resource allocation for SL positioning reference signal Apple
R1-2311748 Remaining issues on resource allocation for SL positioning reference signal Sharp
R1-2311843 Maintenance on Resource Allocation for SL Positioning Reference Signal Samsung
R1-2312035 Resource Allocation for SL-PRS Qualcomm Incorporated
R1-2312125 Remaining issues on resource allocation for SL positioning reference signal LG Electronics
R1-2312157 Remaining issues on resource allocation for SL positioning reference signal CEWiT
R1-2312187 Remaining issues on resource allocation for SL positioning reference signal Ericsson
R1-2312420 Moderator Summary #0 on resource allocation for SL PRS Moderator (Qualcomm)
From Tuesday session
Agreement
For DCI format 3-2, the resource pool index “I” should be an index over the number of dedicated SL PRS resource pools (pre-)configured to the UE.
Conclusion
For sidelink resource allocation scheme 1 (i.e. mode 1 in the specs), dynamic grant, configured grant type 1, and configured grant type 2 are supported for both dedicated and shared SL PRS resource pools.
Agreement
Support the following TP for 38.214 clause 8.2.4.1:
|
In sidelink resource allocation mode 1: - For SL
PRS transmission, |
Agreement
Use SL PRS delay budget instead of packet delay budget in SL PRS resource selection in a dedicated SL PRS resource pool in sidelink resource allocation mode 2.
· Agree the below text proposal on Clause 8.2.4.2 of TS 38.214.
|
<omitted text> The UE shall perform this procedure according to clause 8.1.4, with the following modifications: - “packet delay budget” is replaced by “SL PRS delay budget” <omitted text> |
Conclusion
For a dedicated resource pool, the periodicity of SL PRS cannot be restricted by congestion control.
Agreement
The TP below is endorsed
|
Reason for change: |
Correction on step 6 of SL-PRS resource allocation |
|
|
|
|
Summary of change: |
In clause 8.2.4.2, add modification on step 6 regarding the SL-PRS resource and slot determination based on 8.2.4.2A. |
|
|
|
|
Consequences if not approved: |
The determination of resources applied for SL-PRS resource exclusion is not clear. |
|
*** Unchanged parts are omitted *** 8.2.4.2 UE procedure for determining the subset of resources to be reported to higher layers in SL PRS resource selection in a dedicated SL PRS resource pool in sidelink resource allocation mode 2
In resource allocation mode 2 in a dedicated SL PRS resource pool, the higher layer can request the UE to determine a subset of resources from which the higher layer will select resources for SL PRS/PSCCH transmission. To trigger this procedure, in slot n, the higher layer provides the following parameters for this SL PRS/PSCCH transmission: *** Unchanged parts are omitted *** The UE shall perform this procedure according to clause 8.1.4, with the following modifications: - Partial sensing is not applicable in a dedicated SL PRS resource pool; - A
candidate single-slot resource for transmission - "SCI format 1-A” is replaced by “SCI format 1-B", - In
step 5, the second condition is modified as follows: for any
periodicity value allowed by the higher layer parameter reservationPeriodAllowed-Dedicated-SL-PRS-RP
and
any SL PRS resource ID in the set of SL PRS resource ID(s) provided by the
higher layer,
and
a
hypothetical
SCI format 1-B received in slot - In condition c of step 6 “determines according to clause 8.1.5 the set of resource blocks and slots” is replaced by “determines according to clause 8.2.4.2A the set of SL PRS resources and slots”. *** Unchanged parts are omitted *** |
Agreement
With regards to the UE SL PRS preparation procedure time, the TP below is endorsed
· Note to the editor of TS 38.214: it is up to the editor whether to create a new section or add this text to an existing section as appropriate
|
In sidelink resource allocation mode 1 for a dedicated SL PRS resource pool, the UE shall perform this procedure according to clause 8.6 (excluding the case of PSSCH for retransmission of a transport block), with the following modifications: - "PSSCH for a transport block" is replaced by "SL PRS" - "PSSCH" is replaced by "SL PRS" |
Agreement
The TPs below related to the description of SCI format 2-D are endorsed
· In clause 8.1.3/8.2.1/8.3/8.5.1.2/8.5.2.2/8.5.2.3 of TS 38.214, SCI format 2-D is captured as shown below:
|
-------------------------- Start of text proposal to TS 38.214 v18.0.0 with draft CR R1-2310764------------------------- 8.1.3 Modulation order, target code rate, redundancy version and transport block size determination The
redundancy version is given by the "Redundancy version" field in
SCI format 2-A, 2-B, <<< UNCHANGED PARTS OMITTED >>> 8.2.1 CSI-RS transmission procedure A UE transmits sidelink CSI-RS within a unicast PSSCH transmission if the following conditions hold: · - CSI reporting is enabled by higher layer parameter sl-CSI-Acquisition; and · - the
'CSI request' field in
the corresponding SCI format 2-A, <<< UNCHANGED PARTS OMITTED >>> 8.3 UE procedure for receiving the physical sidelink shared channel For
sidelink resource allocation mode 1, a UE upon detection of SCI format 1-A on PSCCH
can decode PSSCH
according to the detected SCI formats 2-A, 2-B, For
sidelink resource allocation mode 2, a UE upon detection of SCI format 1-A on PSCCH
can decode PSSCH
according to the detected SCI formats 2-A, 2-B, A
UE is required to decode neither the corresponding SCI formats 2-A, 2-B, <<< UNCHANGED PARTS OMITTED >>> 8.5.1.2 Triggering of sidelink CSI reports The CSI-triggering UE is not allowed to trigger another
aperiodic CSI report for the same UE before the last slot of the expected
reception or completion of the ongoing aperiodic CSI report associated with
the SCI format 2-A , An
aperiodic CSI report is triggered by an SCI format 2-A,
<<< UNCHANGED PARTS OMITTED >>> 8.5.2.2 Reference signal (CSI-RS) The UE can be configured with one CSI-RS pattern as indicated by the higher layer parameters sl-CSI-RS-FreqAllocation, sl-CSI-RS-FirstSymbol in SL-CSI-RS-Config. Parameters for which the UE shall assume non-zero transmission power for CSI-RS are configured according to clause 8.2.1. A UE is not expected to be configured such that a CSI-RS and the corresponding PSCCH can be mapped to the same resource element. A UE is not expected to receive sidelink CSI-RS and PSSCH DM-RS, nor CSI-RS and 2nd-stage SCI, on the same symbol. Sidelink CSI-RS shall be transmitted according to [4, TS 38.211]
in the resource blocks used for the PSSCH associated with the SCI format 2-A,
<<< UNCHANGED PARTS OMITTED >>> -------------------------- End of text proposal to TS 38.214 v18.0.0 with draft CR R1-2310764------------------------- |
Agreement
The following TP for TS 38.214 Clause 8.1 is endorsed
|
Reasons for change |
The description of UE setting ‘Embedded SCI format’ field of SCI format 2-D is not correct. |
|
Summary of change |
Change the description of UE setting ‘Embedded SCI format’ field of SCI format 2-D. |
|
Consequences if not approved |
The specification is not aligned with the agreement. |
|
Text proposal |
The UE shall set the contents of the SCI format 2-D as follows: · - the UE shall set value of the '[SL PRS resource ID]' field as indicated by higher layers. · - the UE shall set value of the '[SL PRS request]' field as indicated by higher layers. · - the UE shall set value of the '[Embedded SCI format]' field as indicated by higher layers. · - if 'Embedded SCI format' indicates that SCI format 2-A is embedded within this SCI format 2-D then the UE shall include in the '[Embedded SCI format payload]' field the fields of SCI format 2-A, set as specified above. · - if 'Embedded SCI format' indicates that SCI format 2-B is embedded within this SCI format 2-D then the UE shall include in the '[Embedded SCI format payload]' field the fields of SCI format 2-B, set as specified above. |
R1-2312472 Moderator Summary #1 on resource allocation for SL PRS Moderator (Qualcomm)
From Thursday session
Conclusion
With regards to the SL PRS (re)transmission(s):
· RAN1 assumes that higher layers may provide to PHY layer more than one SL-PRS resource(s), which are used for the (re-)transmission of multiple SL-PRS(s) on different slots to the same target UE(s)
o It is up to RAN2 to specify a mechanism for selection of multiple resources for SL-PRS.
Conclusion
“Maximum Number of SL PRS (re-)transmissions” parameter is applicable to SL-PRS resource (re)-selection.
Agreement
Modify the description of current specification associated with definition of SL PRS-CBR and adopt TP #4 for TS38.215.
|
TP #4
-------------------------- Start of text proposal to TS 38.215 v18.0.0 with draft CR R1-2310743------------------------- 5.1.49 Sidelink PRS channel busy ratio (SL PRS-CBR)
· NOTE 1: The slot index is based on physical slot index. --- unchanged text omitted --- -------------------------- End of text proposal to TS 38.215 v18.0.0 with draft CR R1-2310743------------------------- |
Conclusion
For a dedicated SL-PRS resource pool, for comparing priority between SL-PRS and UL, support two threshold parameters, similar to legacy, which are used for comparing SL-PRS priority versus the threshold,
· if the priority value of SL-PRS is lower than the threshold, SL-PRS has higher priority;
· otherwise, UL has higher priority.
Note: No RAN1 specification change is expected from the above.
Agreement
The TP below is endorsed for TS38.214
-------------------------- Start of text proposal to TS 38.214 v18.0.0 with draft CR R1-2310764------------------------- 8.2.4.1.1 Resource allocation in time domain The UE shall transmit the SL PRS in the same slot as the associated PSCCH. For a dedicated SL PRS resource pool, the minimum resource allocation unit in the time domain is a SL PRS resource in a slot. The UE shall transmit the SL PRS in consecutive symbols within the slot. A UE does not transmit multiple SL PRS resources in the same slot. <<< UNCHANGED PARTS OMITTED >>> 8.2.4.2 UE procedure for determining the subset of resources to be reported to higher layers in SL PRS resource selection in a dedicated resource pool in sidelink resource allocation mode 2 <<< UNCHANGED PARTS OMITTED >>> The UE shall perform this procedure according to clause 8.1.4, with the following modifications: - Partial sensing is not applicable in a dedicated SL PRS resource pool; - ‘Candidate single-slot resource’ is replaced by ’candidate SL PRS resource’. - A
candidate - "SCI format 1-A” is replaced by “SCI format 1-B", - In
step 5, the second condition is
modified as follows: for any periodicity value allowed by the higher layer
parameter reservationPeriodAllowed-Dedicated-SL-PRS-RP and
any SL PRS resource ID in the set of SL PRS resource ID(s) provided by the
higher layer, and
a hypothetical SCI
format 1-B received in slot - In condition b of step 6, the RSRP measurement is the PSCCH-RSRP over the DM-RS resource elements of the PSSCH; - In
condition c of step 6 "determines according to clause 8.1.5 the set of
resource blocks and slots" is replaced by "determines according to
clause 8.2.4. <<< UNCHANGED PARTS OMITTED >>> -------------------------- End of text proposal to TS 38.214 v18.0.0 with draft CR R1-2310764------------------------- |
Agreement
Send an LS to RAN2 and RAN3 with the following:
· From RAN1 perspective, for scheme 1, it is important for the following request to be specified:
o a gNB is able to receive a request from either LMF or UE for SL-PRS bandwidth
· Action to RAN2 and RAN3 to consider how to specify support for such request, if not already specified.
Comeback for draft LS on Friday.
R1-2312629 Draft LS on the request for specific SL PRS resource characteristic(s)/SL-PRS resource configuration Qualcomm Incorporated
Friday decision: The draft LS in R1-2312629 is endorsed, with clarification that it goes to RAN WG2 and RAN WG3. Final LS is approved in R1-2312630.
Agreement
The total number of SL configured grants (including both Type1 and Type2) at a UE across all resource pools is not larger than 8.
Agreement
For support of IUC in shared SL PRS resource pool, value 1 of parameter sl-TriggerConditionRequest means the explicit request can be triggered only when UE-B has data or SL PRS to be transmitted to UE-A.
· Including this into the higher parameter list.
R1-2310839 Maintenance of CPP Huawei, HiSilicon
R1-2310978 Remaining issues on NR DL and UL carrier phase positioning Nokia, Nokia Shanghai Bell
R1-2311097 Remaining issues on carrier phase positioning vivo
R1-2311144 Maintenance for DL and UL Carrier Phase Positioning Intel Corporation
R1-2311166 Remaining issues on NR DL and UL carrier phase positioning Spreadtrum Communications
R1-2311224 Remaining Issues of NR carrier phase positioning OPPO
R1-2311342 Maintenance issues on NR DL and UL carrier phase positioning CATT
R1-2311404 Remaining issues on NR DL and UL carrier phase positioning xiaomi
R1-2311459 Maintenance on carrier phase positioning ZTE
R1-2311598 Remaining issues for positioning based on NR carrier phase measurement InterDigital, Inc.
R1-2311622 Remaining issues on NR DL and UL carrier phase positioning NTT DOCOMO, INC.
R1-2311685 Remaining Issues On NR DL and UL carrier phase positioning Apple
R1-2311844 Maintenance on NR DL and UL Carrier Phase Positioning Samsung
R1-2311911 Remaining issues on carrier phase positioning in NR LG Electronics
R1-2311950 CPP Maintenance Discussion Lenovo
R1-2312036 NR Carrier Phase Positioning Qualcomm Incorporated
R1-2312119 Remaining issues on NR DL and UL carrier phase positioning Ruijie Network Co. Ltd
R1-2312188 Remaining issues on NR DL and UL carrier phase positioning Ericsson
R1-2312269 FL Summary #1 for maintenance on NR DL and UL carrier phase positioning Moderator (CATT)
From Monday session
From AI 5
R1-2310789 Reply LS on R1-2308644 for CPP RAN2, CATT
Decision: To be handled in agenda item 8.3 - To be moderated by Ren Da (CATT).
Agreement
Answer to Q1 as follows:
The associated resource ID and resource Set ID in the report of RSCP can be one of the resource ID(s) and resource Set ID(s) used to obtain the associated UE Rx-Tx time difference when UE report these measurements, as explained below.
Each DL RSCP measurement is obtained from a single DL PRS resource, and each DL RSCP measurement is associated with a single UE Rx-Tx time difference measurement.
The DL PRS resource used to obtain the DL RSCP is:
· the same as the DL PRS resource used to obtain the associated UE Rx-Tx time difference measurement, if the DL UE Rx-Tx time difference is obtained from a single DL PRS resource, or
· one of the DL PRS resources used to obtain the associated UE Rx-Tx time difference measurement, if the DL UE Rx-Tx time difference is obtained from multiple DL PRS resources.
The associated resource IDs and resource Set IDs in the report of RSCPD can be one of the resource IDs and resource Set IDs used to obtain the associated RSTD when UE report these measurements, as explained below.
Each DL RSCPD is obtained from a pair of DL PRS resources, and each DL RSCPD is associated with a single UE RSTD measurement.
The DL PRS resource pair used to obtain the DL RSCPD is:
· the same as the DL PRS resource pair used to obtain the associated UE RSTD measurement, if the DL RSTD is obtained from a pair of DL PRS resources, or
·
one
of the DL PRS resource pairs used to obtain the associated UE RSTD measurement,
if the TOA for DL RSTD is obtained from multiple DL PRS resources pairs, or
from a pair of DL PRS resource sets.
Include the following agreements in RAN1#114bis as a reference:
|
Agreement (RAN1#114bis) The pair of the DL PRS resources used to obtain a DL RSCPD measurement are either the same as the pair of DL PRS resources used to obtain the associated DL RSTD measurement, or one of the pairs of DL PRS resources used to obtain the associated DL RSTD measurement. - Note 1: It has no RAN1 impact. It is up to RAN2 on how the DL PRS resource IDs of DL RSCPD measurements are identified/reported. Agreement (RAN1#114bis) The DL PRS resource used to obtain a DL RSCP measurement is either the same DL PRS resource used to obtain the associated UE Rx-Tx time difference measurement, or one of the DL PRS resources used to obtain the associated UE Rx-Tx time difference measurement. - Note 1: a DL RSCP measurement is obtained by measuring a single DL PRS resource from a TRP. - Note 2: It has no RAN1 impact. It is up to RAN2 on how the DL PRS resource IDs of DL RSCP measurements are identified/reported. |
Agreement
Answer to Q2:
LOS/NLOS indication associated with the resource of RSCP/RSCPD is not required. Rel-17 LOS/NLOS indication for UE RSTD/Rx-Tx time difference measurements applies for the RSCP/RSCPD measurement(s) in the same report.
Agreement
Response to Q3 will be based on the following:
Additional DL/UL RSCP measurements and additional RSCPD measurements are supported.
· For each reported additional UE Rx-Tx time difference/RSTD measurement, support UE to report up to N_sample associated DL RSCP/RSCPD measurements.
· For each reported additional UL RTOA/gNB Rx-Tx time difference measurement, support gNB to report up to N_sample associated UL RSCP measurements.
Agreement
Response to Q4 will be based on the following:
Each indicated DL-PRS resourceSet can be associated with one indicated time window, or two indicated time windows.
Comeback for draft LS
R1-2312392 Draft reply LS on CPP CATT
Wed decision: The draft LS reply to RAN2 in R1-2312392 is endorsed without the note below:
Final LS is approved in R1-2312393.
R1-2312270 FL Summary #2 for maintenance on NR DL and UL carrier phase positioning Moderator (CATT)
From Wednesday session
Agreement
Support the following for the values of the phase quality index and phase quality resolution for the RSCP quality indication:
· phase quality index can be set as [0, …, 179]
· phase quality resolution can be set as [0.1, 1} degree.
Note 1: Reporting “phase quality index” = 179 and “phase quality resolution” = 1 degree implies the phase error may exceed 179 degrees.
Agreement
The TP below is endorsed for TS 38.214
|
Reason for change: |
The number of samples for carrier phase measurements and the timestamp of carrier phase measurements in the following agreement are not accurately captured in the specification: Agreement Subject to UE’s capability, if a UE Rx-Tx time difference/DL RSTD measurement is obtained with Nsample (=2, 4) samples, as defined in TS 38.133, the UE Rx-Tx time difference/DL RSTD measurement can be associated with (i.e., reported together with) up to Nsample RSCP/RSCPD measurements. · A single RSCP/RSCPD measurement is obtained within one sample · Each RSCP/RSCPD measurement has its own timestamp. · Note: It is up to RAN2 on how to define signalling support for the reporting of the timestamps of the RSCP/RSCPD measurements.
|
|
Summary of change: |
Change the description of Section 5.1.6.5.2 in TS 38.214 to accurately capture the agreement. |
|
Consequences if not approved: |
The specification is not aligned with the agreement. |
---------------- Start of TP ----------------
5.1.6.5.2 PRS for carrier phase positioning
<Unrelated part omitted>
The
UE is expected to obtain 1each
DL RSCP or DL RSCPD measurement with 
as defined
in [11, TS 38.133]. If Tthe
UE may reports a DL
RSTD measurement with 
= 2
or 4 samples as defined
in [11, TS 38.133], and
up to DL
RSCPD measurements can be reported
associated
with the DL RSTD measurement. If
Tthe
UE may reports a
UE Rx-Tx time difference measurement with = 2
or 4 samples as defined in [11, TS
38.133], up to and DL
RSCP measurements can be reported
associated
with the UE Rx-Tx time difference measurement. Each DL RSCP or
DL RSCPD measurement has its own timestamp.
---------------- End of TP ----------------
Agreement
Endorse TP#3 in Section 9 of R1-2312270 for TS 38.214 Clauses 5.1.6.5.
|
Reason for change: |
The following agreement made in RAN1#114bis is not fully or clearly captured in the specification, e.g., the number of windows, the number of the indicated DL PRS resource set(s) for all TRPs should be the same. Agreement (RAN1#114bis) Adopt the following changes to the previous agreement made in RAN1#114:
|
|
|
Summary of change: |
Modify the text to fully capture the agreement. |
|
|
Consequences if not approved: |
Misalignment between the agreement and the specification. |
---------------- Start of TP ----------------
5.1.6.5 PRS reception procedure
===================== Unchanged parts omitted ======================
The
UE, subject to UE capability, may be requested via [higher layer parameter] to
perform positioning measurements on indicated DL PRS resource sets occurring
within one or more two time
window(s) indicated by [higher layer parameter]. Within the
each window indicated by [higher layer
parameter], the UE expects that the indicated DL PRS resource
sets across all dl-PRS-IDs
are from one DL PRS positioning frequency layer, and that
the same number of indicated DL PRS
resource sets associated with each dl-PRS-ID are
the same.
===================== Unchanged parts omitted ======================
---------------- End of TP ----------------
R1-2312271 FL Summary #3 for maintenance on NR DL and UL carrier phase positioning Moderator (CATT)
From Thursday session
Agreement
When an LMF requests a UE, which can be a target UE and a PRU, to perform measurements on indicated DL PRS resource set(s) occurring within an indicated time window.
R1-2310840 Maintenance of LPHAP Huawei, HiSilicon
R1-2310979 Remaining issues on LPHAP Nokia, Nokia Shanghai Bell Late submission
R1-2311098 Remaining issues on low power high accuracy positioning vivo
R1-2311226 Remaining issues of low power high accuracy positioning OPPO
R1-2311343 Maintenance issues on low power high accuracy positioning CATT
R1-2311419 Remaining issues on low power high accuracy positioning NEC
R1-2311460 Maintenance on low power high accuracy positioning ZTE
R1-2311483 Maintenance on low power high accuracy positioning CMCC
R1-2311599 Remaining issues on Low Power High Accuracy Positioning (LPHAP) InterDigital, Inc.
R1-2311623 Remaining issues on low power high accuracy positioning NTT DOCOMO, INC.
R1-2311845 Maintenance on Low Power High Accuracy Positioning Samsung
R1-2312037 Discussion on LPHAP Positioning Qualcomm Incorporated
R1-2312105 Remaining Issues on Low Power High Accuracy Positioning Quectel
R1-2312189 Remaining issues on Low Power High Accuracy Positioning Ericsson
R1-2312302 Summary #1 for low power high accuracy positioning Moderator (Huawei, CMCC)
From Monday session
Agreement
The periodicity value of 20480ms is introduced for positioning SRS for RRC_INACTIVE state.
Conclusion
The periodicity values larger than 10240ms are not introduced for DL PRS in Rel-18.
Agreement
Introduce a new RRC parameter to indicate hyper SFN information in which the positioning SRS is transmitted for the periodicity value of 20480ms.
· The value range is {0, 1} to indicate even or odd hyper SFN.
· The parameter is absent when the periodicity of positioning SRS is less than or equal to 10240ms.
Agreement
· TP#1 in section 2.2 of R1-2312302 is endorsed for TS38.213 clause 4.2.
Agreement
· TP#2 below is endorsed for TS38.213 clause 4.2.
|
Reasons for change |
The condition for maintaining the TA from the last serving cell is unclear – what condition “else” referring to is confusing. |
|
Summary of change |
Remove the confusing wording “else” and reorganize the structure. |
|
Consequences if not approved |
Current wording in the specification is misleading and may cause confusion in implementation. |
|
Text proposal |
4.2 Transmission timing adjustments < Unchanged parts are omitted > If
the received downlink timing changes and is not compensated or is only partly
compensated by the uplink timing adjustment without timing advance command as
described in [10,
TS 38.133],
the UE changes -
if the UE is provided SRS-autonomousTAupdate,
the UE may autonomously update -
< Unchanged parts are omitted > |
R1-2312303 Summary #2 for low power high accuracy positioning Moderator (Huawei, CMCC)
From Wednesday session
Agreement
From RAN1 perspective, for TA adjustment upon cell reselection within the validity area, UE is not expected to reduce the TA value to be a negative value. There is no RAN1 specification impact.
Agreement
For indication of the NCD-SSB as the pathloss reference RS for the positioning SRS resource set configured in the RRCRelease message, the fields PhysCellId and ssb-IndexNcell pertaining to the IE SSB-InfoNCell need to be updated to clarify NCD-SSB can be configured, from RAN1 perspective, for example,
|
physicalCellId This field specifies the physical cell ID of the neighbour cell or NCD-SSB of the serving cell for which SSB configuration is provided. |
|
ssb-IndexNcell This field specifies the index of the SSB for a neighbour cell or of a NCD-SSB of the serving cell. See TS 38.213 [13]. If this field is absent, the UE determines the ssb-IndexNcell of the physicalCellId based on its SSB measurement from the cell. |
R1-2310841 Maintenance of positioning with BW aggregation Huawei, HiSilicon, China Telecom, China Unicom
R1-2310980 Remaining issues on bandwidth aggregation for positioning measurements Nokia, Nokia Shanghai Bell Late submission
R1-2311099 Remaining issues on bandwidth aggregation for positioning measurements vivo
R1-2311145 Maintenance for Bandwidth Aggregation for Positioning Intel Corporation
R1-2311167 Remaining issues on bandwidth aggregation for positioning measurements Spreadtrum Communications
R1-2311225 Remaining Issues of bandwidth aggregation for positioning measurement OPPO
R1-2311344 Maintenance issues on bandwidth aggregation for positioning measurements CATT
R1-2311405 Remaining issues on bandwidth aggregation for positioning measurement xiaomi
R1-2311461 Maintenance on BW aggregation for positioning ZTE
R1-2311464 Summary #1 for BW aggregation positioning Moderator (ZTE)
R1-2311465 Summary #2 for BW aggregation positioning Moderator (ZTE)
R1-2311484 Maintenance on BW aggregation for positioning measurements CMCC
R1-2311600 Remaining issues on bandwidth aggregation for positioning measurements InterDigital, Inc.
R1-2311624 Remaining issues on bandwidth aggregation for positioning measurements NTT DOCOMO, INC.
R1-2311686 Remaining Issues On Bandwidth aggregation for positioning measurements Apple
R1-2311846 Maintenance on Bandwidth Aggregation for Positioning Measurements Samsung
R1-2311912 Remaining issues on Bandwidth aggregation for positioning measurements LG Electronics
R1-2312038 Discussion on Bandwidth aggregation for Positioning Qualcomm Incorporated
R1-2312093 Maintenance for bandwidth aggregation for positioning MediaTek Korea Inc.
R1-2312190 Remaining issues on bandwidth aggregation for positioning measurements Ericsson
R1-2311464 Summary #1 for BW aggregation positioning Moderator (ZTE)
From Monday session
Agreement
The new ReportingGranularityfactor also supports k = {-3, -4, -5, -6} in addition to {-1, -2}
· These k values are applicable for timing measurements for all applicable positioning methods
o Support for both DL and UL
o Support for both FR1 and FR2
· Reply the RAN4 LS R1-2310797, and CC to RAN2 and RAN3.
Comeback for draft LS
R1-2312394 Draft Reply LS on SRS and PRS bandwidth aggregation for positioning Moderator (ZTE)
Wed decision: The draft LS reply to RAN4 in R1-2312394 is endorsed. Final LS is approved in R1-2312395.
Conclusion
With regards to TEG reporting for PRS/SRS bandwidth aggregation, for Rx, a single Rx or RxTx TEG ID is reported for the aggregated measurement.
When the LMF requests aggregated measurements, the following existing requested fields can also be applicable:
Agreement
· Endorse the TP 2.1-2 in section 2.1.2 of R1-2311464 for TS 38.212 clause 7.3.1.1.2
Agreement
· Endorse the TP 3.1-1 in section 3.1.1 of R1-2311464 for TS 38.214 clause 6.2.1.4.2
Agreement
If the UE/gNB reports aggregated timing measurement, the single reported RSRP/RSRPP (if reported) is based on aggregated PRS/SRS resources across aggregated PFLs/carriers.
R1-2311465 Summary #2 for BW aggregation positioning Moderator (ZTE)
From Wednesday session
Agreement
Endorse the TP 2.1-1 in section 2.1.1 of R1-2311465 for TS 38.214 clause 6.2.1.4.2.
Agreement
Endorse the TP 4.1-1 in section 4.1.1 of R1-2311465 for TS 38.214 clause 5.1.6.5.3.
Agreement
The TP below is endorsed for TS38.214
|
TP 10.1-2 |
|
|
Reason for change |
In the current RAN1 specification, it specifies that the UE may assume that the PRS/SRS resources across the linked PRS/SRS resource sets are linked for bandwidth aggregation. If the linked PRS/SRS resource sets satisfy the listed conditions, the UE should assume these resource sets are linked for the bandwidth aggregation. The current “may assume” is not a clear wording. |
|
Summary of change |
The UE should assume or should determine that DL PRS resources across the linked DL PRS resource sets which satisfy the above conditions are linked for bandwidth aggregation. |
|
Consequences if not approved |
The current “may assume” is not a clear wording. |
|
Text proposal |
-------------------------------------- TS 38.214 ----------------------------------------------------- < Unchanged text omitted > 5.1.6.5.3 PRS bandwidth aggregation for positioning measurements When
the UE is expected to perform aggregated measurements for bandwidth
aggregation across DL PRS positioning frequency layers, the UE expects to be
configured with linkage information, via higher layer parameter [linkage],
between DL PRS resource sets across DL PRS positioning frequency layers. For
the linked DL PRS resource sets, the UE is expected to be configured with the
same values of QCL, dl-PRS-Periodicity-and-ResourceSetSlotOffset,
dl-PRS-NumSymbols, dl-PRS-ResourceTimeGap,
dl-PRS-ResourceRepetitionFactor, dl-PRS-ResourceSymbolOffset, dl-prs-MutingBitRepetitionFactor, dl-PRS-CyclicPrefix, comb
size, power per subcarrier, NR-MutingPattern, and NR-DL-PRS-SFN0-Offset,
and the UE is expected to be configured with DL PRS resources that
maintain uniformly spaced DL PRS RE pattern within a symbol across aggregated
DL PRS positioning frequency layers. The UE < Unchanged text omitted > 6.2.1.4.2 SRS bandwidth aggregation for positioning measurements The
UE is expected to be configured with linkage information [linkage] on
SRS resource sets for positioning across two or three CCs which are linked
for bandwidth aggregation. For the linked SRS resource sets, the UE is
expected to be configured with the same values of startPosition,
nrofSymbols, periodicityAndOffset, slotOffset, alpha, p0,
subcarrier spacing, CP, and comb size, and the UE is expected to maintain
phase continuity for the SRS transmission. The UE < Unchanged text omitted > |
Final summary in R1-2312396.
R1-2310823 On remaining open issues and maintenance for RedCap UE Positioning FUTUREWEI
R1-2310842 Maintenance of RedCap positioning Huawei, HiSilicon
R1-2310981 Remaining issues on Positioning for RedCap UEs Nokia, Nokia Shanghai Bell Late submission
R1-2310989 Remaining issues of positioning for RedCap UEs New H3C Technologies Co., Ltd.
R1-2311100 Remaining issues on positioning for RedCap UEs vivo
R1-2311146 Remaining details of Positioning for RedCap Ues Intel Corporation
R1-2311168 Remaining issues on positioning for RedCap UEs Spreadtrum Communications
R1-2311227 Remaining issues of positioning for RedCap UEs OPPO
R1-2311345 Maintenance issues on positioning for RedCap UEs CATT
R1-2311418 Remaining issues on positioning for RedCap UEs NEC
R1-2311462 Maintenance on Positioning for RedCap UEs ZTE
R1-2311485 Maintenance on RedCap UE positioning CMCC
R1-2311601 Remaining issues on positioning for RedCap UEs InterDigital, Inc.
R1-2311625 Remaining issues on positioning for RedCap UEs NTT DOCOMO, INC.
R1-2311687 Remaining Issues On Positioning for RedCap UEs Apple
R1-2311847 Maintenance on Positioning for RedCap UEs Samsung
R1-2311913 Remaining issues on positioning support for RedCap UEs LG Electronics
R1-2312039 Maintenance for Positioning for Reduced Capabilities UEs Qualcomm Incorporated
R1-2312094 Maintenance for RedCap UE for positioning MediaTek Korea Inc.
R1-2312191 Remaining issues on positioning for RedCap Ues Ericsson
R1-2312342 Feature Lead summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
R1-2312343 Feature Lead summary #2 for Positioning for RedCap UEs Moderator (Ericsson)
From Tuesday session
Agreement
Endorse the TP 2.4-1 in section 2.5.1 of R1-2312343.
Agreement
Endorse the TP 2.6-1 in section 2.7.1 of R1-2312343.
Agreement
For the values of the starting slot offset for each of the hops following the first hop in time:
· Alt1: the value range can be {0,1,2…, nrof slot in periodicity -1} in slots for the slot offset.
·
Alt2: the slot
offset for each hop is relative to the preceding hop with range (0,1,2…,6)
· The value range slot offset for each hop applies to both the periodic and semi-persistent SRS.
· The periodicity in PeriodicityandOffset configured for each hop for a SRS resource with Tx hopping must be the same.
Agreement
The configuration of SRS for positioning with Tx hopping including SCS, CP size and reference point for bandwidth determination is common to all configured SRS for positioning with Tx hopping resource(s).
· The configuration for positioning SRS with frequency hopping is outside any data BWP configuration.
R1-2312344 Feature Lead summary #3 for Positioning for RedCap UEs Moderator (Ericsson)
From Wednesday session
Agreement
For measurements based on DL PRS with Rx frequency hopping or UL SRS with Tx hopping:
· UE/gNB can report either a single-hop or multi-hops measurement.
· Indication of which of a single-hop or multi-hops measurement is optionally reported.
o Note: mapping of the indicator to performance requirement(s), or impact to performance requirement(s), is up to RAN4
Agreement
For SRS for positioning with Tx hopping n_0 is the initial frequency hop index defined as n_0=floor(n_FirstHop^RB/(m_hop^SRS-m_overlap^hop))
· No new parameter is defined
Note: the corresponding working assumption from RAN1#114bis is confirmed with this agreement.
R1-2312345 Feature Lead summary #4 for Positioning for RedCap UEs Moderator (Ericsson)
From Thursday session
Agreement
For aperiodic positioning SRS with frequency hopping, switching time to/from active UL BWP is added in the minimal time interval between the last symbol of PDCCH triggering A-SRS and the first symbol of the triggered SRS in the first hop.
Agreement
For the determination of collision between PUSCH or PUCCH and the SRS with tx hopping:
and a PUSCH or
PUCCH transmission
starting in symbol
, where 
is the switching
time to/from the active BWP, the UE shall apply the dropping rules taking
into account: is at least (
+ ) symbols 
is at least N2
symbols
Agreement
The UE is expected to switch back to the active BWP when the time between two consecutive hops exceeds twice the switching time to/from the BWP.
· Note: this is applicable when UTW is configured or not configured.
Conclusion
Comb offset hopping is not supported for positioning SRS with frequency hopping for RedCap UEs.
Agreement
Endorse the TP 2.9-1 in section 2.10.1 of R1-2312344, with deletion of “s” in this text: “in each hops”.
Agreement
Endorse the TP 2.10-1b in section 2.11.1 of R1-2312344
Agreement
Endorse the TP 2.12-1 in section 2.13.1 of R1-2312344
Agreement
Endorse the TP 2.17-1b in section 2.18.1 of R1-2312344
R1-2312652 Feature Lead summary #5 for Positioning for RedCap UEs Moderator (Ericsson)
From Friday session
Agreement
TP 2.8-1b in section 2.9.1 of R1-2312652 is endorsed for Section 6.2.1.4.1 in TS 38.214.
Agreement
Update the earlier agreement as follows:
|
Agreement For RedCap UEs positioning transmitting the UL SRS with frequency hopping, regarding the collisions between other UL and DL signals/channels and the UL SRS with frequency hopping, support both of the following options - Option 1: UL time window where the UE is not expected to transmit other signals/channels and is only expected to transmit FH SRS for positioning. - FFS details of an UL time window - Note: it implies that UE drops the transmission of other signals/channels and transmits SRS for positioning - Option 2: new collision rules between the UL SRS with frequency hopping and other UL and DL signals/channels/. Option 2 can apply without or outside UL time window (i.e. option 1) - FFS: details on the collision rules Note: it is understood that option 2 is a component of the feature for UL SRS Tx hopping (FG 41-5-2), and option 1 is a separate feature group. Note: UE is not expected to be configured with a SRS for positioning hopping cycle, including the switching time from/to active BWP required ahead of the first hop and after the last hop, partially overlapping with UTW. |
R1-2312653 Feature Lead final summary for Positioning for RedCap UEs Moderator (Ericsson)
R1-2401759 Session notes for 8.3 (Maintenance on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
Friday decision: The session notes are endorsed and contents reflected below.
[116-R18-Pos] – Debdeep (Intel)
Email discussion on NR positioning
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2400310 Maintenance on expanded and improved NR positioning CMCC
R1-2401162 Maintenance on Resource allocation for SL PRS ASUSTeK
Maintenance on LPHAP
R1-2400219 Maintenance on Rel-18 Positioning vivo
R1-2401073 Maintenance on expanded and improved NR positioning ZTE
R1-2401351 Remaining issues on expanded and improved NR positioning Ericsson
R1-2401628 Summary #1 for low power high accuracy positioning Moderator (CMCC)
Agreement
The TP below is endorsed.
|
Reasons for change |
Align the higher-layer parameters. |
|
Summary of change |
Update higher-layer parameter name in TS 38.211 Clause 6.4.1.4.4. |
|
Consequences if not approved |
The higher layer parameters in TS 38.211 are not aligned with TS 38.331. |
|
Text proposal |
6.4.1.4.4 Sounding reference signal slot configuration Throughout this clause, when the higher layer parameter SRShoppingNrofHops is provided for SRS-PosResource, the sounding reference signal slot configuration applies to a given hop. For
an SRS resource configured as periodic or semi-persistent by the higher-layer
parameter resourceType, a periodicity
and,
if the higher-layer
parameter srs-PosHyperSFN-Index
where
|
Agreement
· Endorse TP 6-2 in Section 6 of R1-2401628 for TS 38.213 Clause 7.3.1 to align the higher layer parameters with TS 38.331.
Agreement
· Endorse TP 6-3 in Section 6 of R1-2401628 for TS 38.214 Clause 6.2.1.4 to align the higher layer parameters with TS 38.331.
Agreement
The TP below is endorsed for TS 38.211 Clause 6.4.1.4.4.
|
Reasons for change |
Avoid the case where there are multiple SRS instances in a hyper-frame when the period is 20480ms. |
|
Summary of change |
Add a description to avoid the case where there are multiple SRS instances in a hyper-frame when the period is 20480ms. |
|
Consequences if not approved |
The specification is not completed. |
|
Text proposal |
6.4.1.4.4 Sounding reference signal slot configuration Throughout this clause, when the higher layer parameter SRShoppingNrofHops is provided for SRS-PosResource, the sounding reference signal slot configuration applies to a given hop. For
an SRS resource configured as periodic or semi-persistent by the higher-layer
parameter resourceType, a periodicity
and,
if the higher-layer
parameter XXX configured for periodicity larger than or
equal to
where |
Agreement
The TP below is endorsed for TS 38.214 Clause 6.2.1.
|
Reasons for change |
The current specification text in 38.214 does not include the description for the hyper SFN parameter of the SRS for positioning in LPHAP. |
|
Summary of change |
Include Hyper SFN parameter for SRS configuration for TS 38.214 Clause 6.2.1. |
|
Consequences if not approved |
Incomplete description of SRS configuration. |
|
Text proposal |
6.2.1 UE sounding procedure < Unchanged parts are omitted > The following SRS parameters are semi-statically configurable by higher layer parameter SRS-Resource or SRS-PosResource. - srs-ResourceId or SRS-PosResourceId determines SRS resource configuration identity. - Number of SRS ports, as defined by the higher layer parameter nrofSRS-Ports and described in clause 6.4.1.4 of [4, TS 38.211]. If not configured, nrofSRS-Ports is 1. - Time domain behaviour of SRS resource configuration as indicated by the higher layer parameter resourceType, which may be periodic, semi-persistent, aperiodic SRS transmission as defined in clause 6.4.1.4 of [4, TS 38.211]. - Slot level periodicity and slot level offset as defined by the higher layer parameters periodicityAndOffset-p or periodicityAndOffset-sp for an SRS resource of type periodic or semi-persistent. The UE is not expected to be configured with SRS resources in the same SRS resource set SRS-ResourceSet or SRS-PosResourceSet with different slot level periodicities. For an SRS-ResourceSet configured with higher layer parameter resourceType set to 'aperiodic', a slot level offset is defined by the higher layer parameter slotOffset. For an SRS-ResourceSet configured with higher layer parameter resourceType set to 'aperiodic', a list of up to four different available slot offset values from the reference slot n + k to the slot where the aperiodic SRS resource set is transmitted where n is the slot with triggering DCI and k is slotOffset, can be configured by the higher layer parameter availableSlotOffsetList. The parameter availableSlotOffsetList can be configured up to 4 different values. For an SRS-PosResourceSet configured with higher layer parameter resourceType set to 'aperiodic', the slot level offset is defined by the higher layer parameter slotOffset for each SRS resource. - srs-PosHyperSFN-Index indicates whether the current hyper-frame number is even or odd for SRS for positioning transmission, if configured. < Unchanged parts are omitted > |
Maintenance on NR DL and UL carrier phase positioning
R1-2400138 Maintenance of expanded and improved NR positioning Huawei, HiSilicon
R1-2400191 Remaining issues on NR Positioning Nokia, Nokia Shanghai Bell
R1-2400219 Maintenance on Rel-18 Positioning vivo
R1-2400409 Maintenance on Expanded and Improved NR Positioning CATT, CICTCI
R1-2400580 Text Proposals on Expanded and Improved NR Positioning OPPO
R1-2400708 Maintenance on Expanded and Improved NR Positioning Samsung
R1-2400989 Remaining Issues On Expanded and Improved Positioning Apple
R1-2401073 Maintenance on expanded and improved NR positioning ZTE
R1-2401485 FL Summary #1 for maintenance on NR DL and UL carrier phase positioning Moderator (CATT)
Agreement
Endorse the TP below for TS 38.214 Clauses 5.1.6.5.
|
Reason for change: |
A Rel-17 UE can perform positioning measurements inside measurement gap or PPW. According to the agreements of the 3GPP RAN1#113, a Rel-18 UE can only perform CPP positioning measurements within measurement gap.
In Rel-18, the DL RSCPD and/or DL RSCP can be reported together with the Rel-16 timing measurement (RSTD / UE Rx-Tx time difference), but it needs to be clarified at 38.214 that a Rel-18 UE can only perform CPP measurement within MG.
Agreement Support the reuse of existing physical layer procedures for DL positioning (e.g., DL-TDOA) with the necessary enhancements in measurement configuration, request and report (e.g., adding the configuration related to the NR DL CPP) for both UE-based and UE-assisted NR DL carrier phase positioning, including · UE in RRC_CONNECTED state with measurement gap. · FFS: UE in RRC_CONNECTED state without measurement gap · UE in RRC_ INACTIVE state
Conclusion From RAN1’s perspective, carrier phase positioning for UE in RRC_CONNECTED state without measurement gap is not supported in Rel-18.
Agreement From RAN1’s perspective, carrier phase positioning for UE in RRC_IDLE state is supported for UE-based and UE-assisted positioning in Rel-18. · Note: No additional specification work is expected specifically related to carrier phase positioning for UE in RRC_IDLE state in RAN1.
|
|
Summary of change: |
In clause 5.1.6.5 of TS 38.214, add the UE behavior that a Rel-18 UE can only perform DL RSCPD and/or DL RSCP measurements in measurement gap.
|
|
Consequences if not approved: |
The UE behavior for DL RSCPD and/or DL RSCP measurement is not clearly defined. |
-------------------------------------------- Start of text proposal to TS 38.214 v18.1.0 ---------------------------------------
5.1.6.5.2 PRS for carrier phase positioning
For DL UE positioning measurement reporting in higher layer parameter NR-DL-TDOA-SignalMeasurementInformation, the UE may be configured to report the DL Reference Signal Carrier Phase Difference (RSCPD) [7, TS 38.215] measurement along with the DL RSTD. When the UE reports RSCPD measurements, the reference nr-DL-PRS-ReferenceInfo is the same as the one reported, for the RSTD measurements. For DL UE positioning measurement reporting in higher layer parameter NR-Multi-RTT-SignalMeasurementInformation, the UE may be configured to report the DL Reference Signal Carrier Phase (RSCP) measurement [7, TS 38,215] along with the UE Rx-Tx time difference measurement. When the UE reports DL RSCPD measurement(s) along with DL RSTD measurement(s) or DL RSCP measurement(s) along with UE Rx-Tx time difference measurement(s), the DL RSCPD and/or DL RSCP measurement(s) should be measured from a single DL PRS positioning frequency layer. For a UE in RRC_CONNECTED state, DL RSCP/RSCPD measurements are measured within the configured measurement gap.
-------------------------------------------- End of text proposal to TS 38.214 v18.1.0 ---------------------------------------
Agreement
The TP below is endorsed.
|
Reason for change: |
1) In 5.1.6.5, there is a typo in “within one or more-two time window(s)”, 2) “DL carrier phase measurement” should be replaced with DL RSCP/RSCPD measurement 3) A number of IEs in brackets in 38.214 can be replaced with the IEs defined in TS 37.355. |
|
Summary of change: |
1) Correct the typo 2) Replace “DL carrier phase measurement” with “DL RSCP/RSCPD measurement” 3) Replace the IEs in brackets in 38.214 with the IEs defined in TS 37.355. |
|
Consequences if not approved: |
The specification is not clearly defined. |
-------------------------------------------- Start of text proposal to TS 38.214 v18.1.0 ---------------------------------------
5.1.6.5 PRS reception procedure
===================== Unchanged parts omitted ======================
The
UE, subject to UE capability, may be requested via [higher layer
parameter] to perform DL RSCPD and/or DL RSCP measurements on
indicated DL PRS resource sets occurring within one or more-two
time window(s) indicated by NR-DL-PRS-MeasurementTimeWindowsConfig[nr-timeWindowConfig-DL-Measurements].
Within each window indicated by NR-DL-PRS-MeasurementTimeWindowsConfig
[nr-timeWindowConfig-DL-Measurements], the UE expects that
the indicated DL PRS resource sets across all dl-PRS-IDs are from one DL
PRS positioning frequency layer, and that the number of indicated DL PRS
resource sets associated with each dl-PRS-ID are the same.
The
UE, subject to UE capability, may be requested to perform DL RSTD, UE Rx – Tx
time difference, DL PRS-RSRP, and DL PRS-RSRPP measurement on the indicated DL
PRS resource sets only within the window(s) indicated by DL-PRS-MeasurementTimeWindowsConfig
[nr-timeWindowConfig-DL-Measurements].
==================== Unchanged parts omitted ======================
-------------------------------------------- End of text proposal to TS 38.214 v18.1.0 ---------------------------------------
R1-2401486 FL Summary #2 for maintenance on NR DL and UL carrier phase positioning Moderator (CATT)
Agreement
· TP#4 in R1-2401486 Section7 for TS 38.214 Clause 5.1.6.5 is endorsed.
Final summary in R1-2401487.
Maintenance on bandwidth aggregation positioning
R1-2400138 Maintenance of expanded and improved NR positioning Huawei, HiSilicon
R1-2400191 Remaining issues on NR Positioning Nokia, Nokia Shanghai Bell
R1-2400219 Maintenance on Rel-18 Positioning vivo
R1-2400374 Maintenance issues on Rel-18 Positioning Intel Corporation
R1-2400539 Maintenance on Expanded and Improved NR Positioning xiaomi
R1-2400580 Text Proposals on Expanded and Improved NR Positioning OPPO
R1-2400708 Maintenance on Expanded and Improved NR Positioning Samsung
R1-2400989 Remaining Issues On Expanded and Improved Positioning Apple
R1-2401073 Maintenance on expanded and improved NR positioning ZTE
R1-2401418 Maintenance on Expanded and Improved NR Positioning Qualcomm Incorporated
R1-2401594 Summary #1 for BW aggregation positioning Moderator (ZTE)
Agreement
For PRS/SRS bandwidth aggregation, capture the “single Tx chain” (same Tx antenna) assumption in RAN1 specification. Endorse the TP 2.1-2 in section 2.1 of R1-2401594 for TS 38.214 clause 5.1.6.5.3 and 6.2.1.4.2.
Agreement
RAN1 understands that the current RRC ASN.1 only supports single “aggregated combination”, in which only one SRS resource set from each of the 2 or 3 carriers are aggregated, e.g. CC#1 SRS resource set 1 + CC#2 SRS resource set 2 + CC#3 SRS resource set 3. RAN1 suggests to extend the number of such “aggregated combinations” to up to 32. Send an LS to RAN2 and RAN3.
Conclusion
It is supported that the SCell not configured with DL but contain only positioning SRS in the UL to be aggregated with positioning SRS on another PCell/SCell. Send LS to RAN2.
R1-2401707 Draft LS on bandwidth aggregation for positioning Moderator (ZTE)
Decision: The draft LS to RAN2 and RAN3 in R1-2401707 is endorsed. Final LS is approved in R1-2401708.
Agreement
Endorse the TP below for TS 38.214 clause 6.2.1.4.2
|
Reason for change |
There are brackets in the specification |
|
Summary of change |
Remove the whole bracket and make the spec complete |
|
Consequences if not approved |
The specification is not complete |
|
Text proposal |
---------------------------- Start of Text Proposal for TS 38.214 ---------------------------- 6.2.1.4.2 SRS bandwidth aggregation for positioning measurements < Unchanged parts are omitted > When an SRS resource
configured in a CC without PUSCH or PUCCH is linked for bandwidth aggregation
with an SRS resource configured in an active UL BWP of another ---------------------------- End of Text Proposal for TS 38.214 ---------------------------- |
Agreement
· Endorse the TP 9.1-2 in section 9.1 of R1-2401594 for TS 38.214 clause 5.1.6.5.3 and 6.2.1.4.2
Agreement
· Endorse the TP 10.1-1 in section 10.1 of R1-2401594 for TS 38.214 clauses 5.1.6.5.
Agreement
· Endorse the TP 10.1-2 in section 10.1 of R1-2401594 for TS 38.214 clauses 5.1.6.5.3 and 6.2.1.4.2.
R1-2401595 Summary #2 for BW aggregation positioning Moderator (ZTE)
Agreement
TP 6.2-1 in section 6.2 of R1-2401595 for TS 38.214 clause 5.1.6.5.3 is endorsed.
This does not have LPP impact.
Agreement
· TP 8.1-1 in section 8.1 of R1-2401595 for TS 38.214 clause 5.1.6.5.3 is endorsed.
Maintenance on RedCap positioning
R1-2400138 Maintenance of expanded and improved NR positioning Huawei, HiSilicon
R1-2400191 Remaining issues on NR Positioning Nokia, Nokia Shanghai Bell
R1-2400219 Maintenance on Rel-18 Positioning vivo
R1-2400374 Maintenance issues on Rel-18 Positioning Intel Corporation
R1-2400989 Remaining Issues On Expanded and Improved Positioning Apple
R1-2401039 Discussion on remaining issues for R18 NR positioning InterDigital, Inc.
R1-2401073 Maintenance on expanded and improved NR positioning ZTE
R1-2401247 Maintenance of expanded and improved NR positioning LG Electronics
R1-2401351 Remaining issues on expanded and improved NR positioning Ericsson
R1-2401636 Feature Lead summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
Agreement
· TP 2.2-1 for 38.211 in section 2.2.1 of R1- 2401636 is endorsed.
Agreement
The TP below for 38.211 is endorsed.
|
Reason for change: |
1. 2. Align the typeface and description of the two sentences in the paragraph. |
|
Summary of change: |
Summary
of change: Modify the |
|
Consequences if not approved: |
there are some typos and error issues in the specification |
|
< Unchanged parts are omitted > 6.4.1.4.1 SRS resource - < Unchanged parts are omitted > |
|
Agreement
· TP 2.6-1 for 38.214 in section 2.6.1 of R1- 2401636 is endorsed
Conclusion
The network may configure positioning SRS outside the active UL BWP with Tx hopping configured with the number of hops equal to 1.
R1-2401637 Feature Lead summary #2 for Positioning for RedCap UEs Moderator (Ericsson)
Agreement
For a RedCap UE receiving nr-DL-PRS-RxHoppingTotalBandwidth in location information request, clarify that for each DL-PRS resource, the RedCap UE performs PRS Rx frequency hopping to a bandwidth of min {the requested bandwidth in request location information, the configured DL-PRS bandwidth in the provided assistance data}.
· This clarification has no RAN1 specification impact, but may have impact to other specifications.
· Send an LS to RAN4 and RAN2 with this agreement
R1-2401800 Draft LS on the bandwidth used in measurements for positioning of RedCap UEs Ericsson
Decision: The draft LS in R1-2401800 is endorsed (with the addition of RAN2 in To RAN4). Final LS is approved in R1-2401801.
Final summary in R1-2401638.
Maintenance on SL positioning reference signal
R1-2401547 FL summary #1 on SL positioning reference signal Moderator (Intel Corporation)
Conclusion
Indication of whether same antenna port may be assumed for SL PRS and PSSCH to enable joint processing at UE receiver is not supported in Rel-18.
Agreement
Agree on TP#1 in section 6 of R1-2401547 for Subclause 8.4.1.6.3 of TS 38.211 to capture the transmit power for the AGC symbol associated with SL PRS resource in a dedicated SL PRS resource pool.
Agreement
Agree on TP#3 in section 6 of R1-2401547 for Subclause 8.2.4.1.2 of TS 38.214 to reflect that the bandwidth of SL PRS in a dedicated SL PRS resource pool is same as the resource pool bandwidth in number of RBs of the same resource pool.
Agreement
Agree on TP#4 in section 6 of R1-2401547 for Subclause 16.2.3A of TS 38.213 to correct the reference to higher layer parameter for controlling the maximum transmission power for SL PRS in a dedicated SL PRS resource pool and for alignment of higher layer parameter names.
Agreement
Agree on TP#5 in section 6 of R1-2401547 for Subclause 8.4.1.6.3 of TS 38.211 to improve clarity of the specifications and align with higher layer parameter names in description for mapping of SL PRS to physical resources.
R1-2401548 FL summary #2 on SL positioning reference signal Moderator (Intel Corporation)
Agreement
For SL PRS transmission, the higher layer parameter sl-FilterCoefficient is provided on a per resource pool basis.
· Inform RAN2 to add sl-FilterCoefficient to SL-PRS-ResourcePool. (see approved LS in R1-2401827)
Agreement
TP#6 in Section 8 of R1-2401548 for Subclause 8.2.4 of TS 38.214 is endorsed to improve clarity of the specifications and align with higher layer parameter names for description of SL PRS resource.
Final summary in R1-2401549.
Maintenance on measurements and reporting for SL positioning
R1-2401611 Summary #1 on Measurements and reporting for SL positioning Moderator (vivo)
Agreement
· Endorse the TP 3.1-1 in section 8.1 of R1-2401611 for TS 38.214 clause 8.4.4.
Agreement
· Endorse the TP 3.2-1 in section 8.1 of R1-2401611 for TS 38.214 clause 8.4.4.
Agreement
· Endorse the TP 5.1-1 in section 8.1 of R1-2401611 for TS 38.214 clause 8.4.4.
Final summary in R1-2401613.
Maintenance on resource allocation for SL PRS
R1-2401608 Moderator Summary #0 on resource allocation for SL PRS Moderator (Qualcomm)
Agreement
· Feature Lead Proposal 8-v0 in section 6 of R1-2401608 is agreed with the corresponding TP for 38.214.
Agreement
· Feature Lead Proposal 6-v0 in section 6 of R1-2401608 is agreed with the corresponding TP for 38.213.
Agreement
· Feature Lead Proposal 10-v0 in section 6 of R1-2401608 is agreed with the corresponding TP for 38.214.
Agreement
Send an LS to RAN2 to inform them of the parameter sl-ThreshS-RSSI-PRS-CBR that needs to be introduced in TS 38.331 and is currently missing from the list of higher layer parameters in R1-2312708:
|
Sub-feature group |
RAN1 specification |
Parameter name in the spec |
New or existing? |
Description |
Value range |
Per (UE, cell, TRP, …) |
Required for initial access or IDLE/INACTIVE |
Specification |
|
SL PRS configuration in a dedicated resource pool |
38.215 |
sl-ThreshS- RSSI-PRS-CBR |
New |
Indicates the S-RSSI threshold for determining the contribution of a sub-channel to the SL PRS-CBR measurement in a dedicated SL PRS resource pool. Value 0 corresponds to -112 dBm, value 1 to -110 dBm, value n to (-112 + n*2) dBm, and so on. |
INTEGER (0..45) |
Per dedicated SL PRS resource pool |
Yes |
38.331 |
R1-2401826 Draft LS on higher layer parameters for SL Positioning Moderator (Intel Corporation), Moderator (Qualcomm)
Decision: The draft LS in R1-2401826 is endorsed. Final LS is approved in R1-2401827.
Conclusion
1-symbol PSCCH is not supported for Rel-18.
Agreement
· Feature Lead Proposal 9-v0 in section 6 of R1-2401608 is agreed with the corresponding TP for 38.212.
Agreement
· Feature Lead Proposal 13.4-v0 in section 6 of R1-2401608 is agreed with the corresponding TP for 38.215.
Agreement
· Feature Lead Proposal 13.1-v0 in section 6 of R1-2401608 is agreed with the corresponding TP for 38.212.
R1-2401792 Moderator Summary #2 on resource allocation for SL PRS Moderator (Qualcomm)
Agreement
· Text Proposal 1 for TS38.214 in section 16 of R1-2401792 is endorsed for the editor’s alignment CR.
Agreement
· Text Proposal 2 for TS38.213 in section 16 of R1-2401792 is endorsed for the editor’s alignment CR.
Agreement
The TP below is endorsed for TS38.202.
|
Reason for change |
For the characterization of simultaneous “Reception Type” combinations for sidelink, further qualification would be necessary to describe the scope within which the numbers of simultaneous “Reception Type” combinations apply for SL PRS reception. In particular, - For a shared SL PRS resource pool, the number of simultaneous SL PRS receptions should be defined within one sub-channel to align with SL communications (cf. Note 1 applicable for PSSCH and PSCCH). - For a dedicated SL PRS resource pool, the number of simultaneous SL PRS receptions should be defined within a dedicated SL PRS resource pool (analogous to a sub-channel for SL communications). |
|
Summary of change |
Clarify notes Note 3 and 4 in Table 6.3-4 |
|
Consequences if not approved |
Incomplete/ambiguous specifications: It is unclear as to the time-frequency region within which the maximum numbers of simultaneous receptions of SL PRS for a shared and dedicated SL PRS resource pool is defined. |
< Unchanged text omitted >
Table 6.3-4: Sidelink "Reception Type" combinations
|
Supported Combinations |
Comment |
|
A |
|
|
B |
Note 1, Note 2 |
|
C |
Note 1, Note 2 |
|
E |
Note 3 |
|
|
Note 4 |
|
|
Note 2 |
|
B+C |
Note 1, Note 2 |
|
Note 1: Corresponds to simultaneous reception within one sub-channel Note 2: Depending on the UE capability, the UE may be able to perform simultaneous sidelink communication receptions of the same sidelink “Reception Type” combinations across multiple SL carriers. Note 3: Applicable for a shared SL PRS resource pool. Corresponds to simultaneous reception within one sub-channel. Note 4: Applicable for a dedicated SL PRS resource pool with M1≥1. Corresponds to simultaneous reception within one dedicated SL PRS resource pool. |
|
< Unchanged text omitted >
Working assumption
In NR Rel-18, in a band (pre)configured with SL CA, SL PRS transmission /reception can be supported:
Note: whether this combination of features is supported in Rel-18 requires a conclusion on whether to introduce new UE capability(ies). No specification work until the FFS is resolved.
From AI 5
LS on MAC agreements for SL positioning
R1-2400008 LS on MAC agreements for SL positioning RAN2, Huawei
R1-2401550 Moderator summary #1 on RAN2 LS on MAC agreements for SL Positioning Moderator (Intel Corporation)
Agreement
To the following question from RAN2 in R1-2400008, RAN1 to respond as below:
· Question from RAN2:
o On the maximum number of parallel SL-PRS transmission
§ What is the maximum total number of parallel SL-PRS transmission on SL-PRS shared/dedicated resource pool?
· RAN1’s response: While the interpretation intended by RAN2 for “parallel SL PRS transmission” is not fully clear, RAN1 understands that it is referring to the number of processes similar to the number of SL processes associated with a SL HARQ entity for SL communications. There is no concept of parallel SL PRS transmission processes defined/used in RAN1 and such a concept is expected to be transparent to RAN1 specifications. Accordingly, the maximum total number of parallel SL PRS transmission in a shared/dedicated SL PRS resource pool can be up to RAN2.
Agreement
To the following question from RAN2 in R1-2400008, RAN1 to respond as below:
· Question from RAN2:
o On the maximum number of parallel SL-PRS transmission
§ What is the maximum number of parallel SL-PRS transmission supported on a SL-PRS shared resource pool and SL-PRS dedicated resource pool, respectively?
· RAN1’s response: Following from the response to the first question, the maximum number of parallel SL PRS transmission in a shared/dedicated SL PRS resource pool respectively can be up to RAN2.
Agreement
To the following question from RAN2 in R1-2400008, RAN1 to respond as below:
· Question from RAN2:
o When SL-PRS is transmitted on a SL-PRS shared resource pool where PSFCH is configured, if the associated PSSCH transmission is positively acknowledged, should the UE continue to perform SL-PRS retransmission?
· RAN1’s response: Since there is no notion of Layer 1 feedback in response to SL PRS transmission, a positive acknowledgement for an associated PSSCH may not be interpreted to indicate successful reception of SL PRS (see RAN1 conclusion from RAN1 #113 below). Accordingly, a Tx UE may continue to perform SL PRS retransmissions if it has been provided with multiple resources for (re-)transmission by the MAC layer, subject to any restrictions on the maximum number of retransmissions.
|
Conclusion Do not support ACK/NACK feedback for SL-PRS or lower-layer feedback-based retransmissions in Release 18. |
R1-2401551 Draft Reply LS on MAC agreements for SL Positioning Moderator (Intel Corporation)
Decision: The draft LS in R1-2401551 is endorsed (with the addition of the missing conclusion). Final LS is approved in R1-2401552.
R1-2401828 List of RAN1 agreements for Rel-18 Positioning Moderator (Intel Corporation)
R1-2403652 Session notes for 8.2 (Maintenance on expanded and improved NR positioning) Ad-Hoc Chair (Huawei)
Friday decision: The session notes are endorsed and contents (inc. Friday updates) reflected below.
[116bis-R18-Pos] – Debdeep (Intel)
Email discussion on NR positioning
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2403742 List of RAN1 agreements for Rel-18 Positioning Moderator (Intel Corporation)
R1-2402035 Maintenance of Rel-18 positioning Huawei, HiSilicon
R1-2402092 Maintenance on Expanded and Improved NR Positioning Nokia
R1-2402142 Maintenance issues on Rel-18 Positioning Intel Corporation
R1-2402212 Maintenance on Rel-18 Positioning vivo
R1-2402300 Text Proposals on Expanded and Improved NR Positioning OPPO
R1-2403410 Maintenance on Expanded and Improved NR Positioning CATT, CICTCI (rev of R1-2402358)
R1-2402432 Remaining Issues on NR positioning Samsung
R1-2402701 Maintenance on expanded and improved NR positioning ZTE Corporation
R1-2402865 Remaining Issues on Expanded and Improved Positioning Apple
R1-2403104 Maintenance on Resource allocation for SL PRS ASUSTeK
R1-2403170 Maintenance on Expanded and Improved NR Positioning Qualcomm Incorporated
R1-2403263 Maintenance of expanded and improved NR positioning LG Electronics
R1-2403318 Remaining issues on expanded and improved NR positioning Ericsson
R1-2403465 FL summary #1 on SL positioning reference signal Moderator (Intel Corporation)
From Monday session
Agreement
Agree on TP#2 in Section 4 of R1-2403465 for Subclause 16.2.3A of TS 38.213 to align parameter name for power control parameter for SL PRS.
Agreement
Agree on TP#4 in Section 4 of R1-2403465 for TS 38.211, Clauses 8.2.1 and 8.4.1.6.3 to correct description associated with AGC symbol associated with SL PRS transmission in dedicated SL PRS resource pool.
Agreement
Agree on TP#5 in Section 4 of R1-2403465 for TR 38.859, Table A.1-3 to correct incorrect evaluation assumptions for highway and urban grid scenarios for V2X use-case.
Comeback for final CR (Debdeep)
R1-2403620 Corrections on the support for Expanded and Improved NR Positioning Intel Corporation (Moderator), CATT, CICTCI
Decision: Final CR (Rel-18, 38.859, FS_NR_pos_enh2, CR0001, Cat F) is agreed.
Agreement
Agree on TP#6A in Section 4 of R1-2403465 for Clause 8.2.4 of TS 38.214 to remove duplication of statement in TS 38.214 regarding SL PRS and associated PSCCH being in the same slot.
Final summary in:
R1-2403466 FL summary #2 on SL positioning reference signal Moderator (Intel Corporation)
R1-2403419 FL Summary #1 for maintenance on NR DL and UL carrier phase positioning Moderator (CATT)
From Monday session
Conclusion
No further discussion in RAN1 on the definition of center frequency of the NR carrier phase measurements in Rel-18.
Agreement
TP#1 in R1-2403419 Section 3 for TS38.214 Clause 5.1.6.5.2 is agreed for editor’s alignment CR.
Final summary in R1-2403420.
R1-2403543 Moderator Summary #0 on resource allocation for SL PRS Moderator (Qualcomm)
From Monday session
Agreement
For a band configured with SL CA, confirm the related working assumption from RAN1 #116 with the introduction of the following new UE capabilities:
o One UE capability for SL PRS transmission for a band configured with SL CA
o One UE capability for SL PRS reception for a band configured with SL CA
o Note: there will not be two separate FG components for shared RP and dedicated RP
Agreement
The TP below for 38.214 Section 8.2.4.3 is endorsed
· Reason for change: The new processing timing capability 3 is introduced for SL-PRS Congestion control.
· Summary of change: Capture the new processing timing capability 3 for SL-PRS Congestion control.
· Consequences if not approved: The new processing timing capability 3 is missing in the specification.
|
When transmitting SL-PRS in a dedicated SL PRS resource pool the UE shall perform sidelink congestion control as specified in clause 8.1.6, with the following modification(s): - "PSSCH" is replaced by "SL PRS" - [potential parameter name changes] - the congestion control processing time N is based on µ of Table 8.1.6-1, Table 8.1.6-2 and Table 8.2.4.3-1 for UE processing capability 1, 2 and 3 respectively, where µ corresponds to the subcarrier spacing with which the SL PRS is to be transmitted. A UE shall only apply a single processing time capability in SL-PRS congestion control in dedicated SL PRS resource pool.
Table 8.2.4.3-1: Congestion control processing time for processing timing capability 3
|
Agreement
· Send LS to RAN2 for the feature of UE reporting SL PRS CBR measurement to gNB:
|
Sub-feature group |
RAN1 specification |
Parameter name in the spec |
New or existing? |
Description |
Value range |
Per (UE, cell, TRP, …) |
Required for initial access or IDLE/INACTIVE |
Specification |
|
Measured result for NR sidelink |
|
measResultListCBR-Dedicated-SL-PRS-NR |
New |
Indicates the list of SL PRS CBR measurement results for NR sidelink positioning for dedicated SL PRS resource pool |
SEQUENCE (SIZE (1.. maximum number of dedicated SL PRS resource pool to measure)) OF measResultCBR-Dedicated-SL-PRS-NR |
Per UE |
/ |
38.331 |
|
Measured result for NR sidelink |
|
measResultCBR-Dedicated-SL-PRS-NR |
New |
Indicates the SL PRS CBR measurement results for NR sidelink positioning for dedicated SL PRS resource pool |
SL-CBR-Dedicated-SL-PRS-RP (0 … 100) and SL-PRS-ResourcePoolID |
Per UE |
/ |
38.331 |
Comeback for draft LS (Alex)
R1-2403576 Draft LS on UE’s reporting SL PRS CBR measurement to gNB Qualcomm Incorporated
Decision: The draft LS in R1-2403576 is endorsed. Final LS is approved in R1-2403577.
Agreement
The TP below for TS 38.214 Section 8.3 is endorsed:
---------------------------------------< Text Proposal #7 for 38.214> -------------------------------------- 8.3 UE procedure for receiving the physical sidelink shared channel For sidelink resource allocation mode 1, a UE upon detection of SCI format 1-A on PSCCH can decode PSSCH according to the detected SCI formats 2-A, 2-B, 2-C and 2-D, and associated PSSCH resource configuration configured by higher layers. The UE is not required to decode more than one PSCCH at each PSCCH resource candidate. For sidelink resource allocation mode 2, a UE upon detection of SCI format 1-A on PSCCH can decode PSSCH according to the detected SCI formats 2-A, 2-B, 2-C and 2-D, and associated PSSCH resource configuration configured by higher layers. The UE is not required to decode more than one PSCCH at each PSCCH resource candidate. A UE is required to decode neither the corresponding SCI formats 2-A, 2-B, 2-C, 2-D nor the PSSCH associated with an SCI format 1-A if the SCI format 1-A indicates an MCS table that the UE does not support. -----------------------------------< End of Text Proposal #7 for 38.214> ------------------------------- |
Agreement
The TP below for TS 38.214 Section 8.1 is endorsed.
|
-------------------------- Start of text proposal #13.2 to TS 38.214 v18.2.0 --------------------------- 8.1 UE procedure for transmitting the physical sidelink shared channel <<< UNCHANGED PARTS OMITTED >>> The UE shall set the contents of the SCI format 2-D as follows: - the
UE shall set value of the ' - the
UE shall set value of the ' - the
UE shall set value of the ' - if 'Embedded
SCI format' indicates that SCI format 2-A is embedded within this SCI
format 2-D then the UE shall include in the ' - if 'Embedded SCI format'
indicates that SCI format 2-B is embedded within this SCI format 2-D then the
UE shall include in the ' <<< UNCHANGED PARTS OMITTED >>> -------------------------- End of text proposal #13.2 to TS 38.214 v18.2.0 --------------------------- |
R1-2403564 Moderator Summary #1 on resource allocation for SL PRS Moderator (Qualcomm)
From Thursday session
Agreement
With regards to the dci-FormatsSL and in relation to DCI format 3_2:
R1-2403731 Draft LS on the dci-FormatsSL and DCI format 3_2 Qualcomm Incorporated
Friday decision: The draft LS in R1-2403731 is endorsed. Final LS is approved in R1-2403732.
R1-2403426 Summary #1 for BW aggregation positioning Moderator (ZTE)
Agreement
TP 2.1-1a in section 2.1 of R1-2403426 for TS 38.214 clause 6.2.1.4.2 is endorsed.
Agreement
TP 5.1-1 in section 5.1 of R1-2403426 for TS 38.214 clause 5.1.6.5 is endorsed as editorial correction.
R1-2403427 Summary #2 for BW aggregation positioning Moderator (ZTE)
R1-2403612 Summary #3 for BW aggregation positioning Moderator (ZTE)
From Thursday session
Agreement
· Send an LS to RAN2 indicating that at least one PRS resource ID from one of aggregated resource sets may be reported in one measurement report element for the main and additional measurements, respectively. The existing PRS resource ID can be reused, details up to RAN2.
Comeback for draft LS (Chuangxin)
R1-2403717 Draft LS on PRS resource ID for bandwidth aggregation Moderator (ZTE)
Decision: The draft LS in R1-2403717 is endorsed with the following revision:
·
However, from RAN1 perspective, PRS resource
ID is
can be optionally needed reported for
PRS bandwidth aggregation.
Hence, RAN1 made the following agreement.
Final LS is approved in R1-2403728.
R1-2403519 Feature Lead summary #1 for Positioning for RedCap UEs Moderator (Ericsson)
From Monday session
Agreement
The TP 2.7-1 in section 2.7.1 of R1- 2403519 is endorsed for inclusion in 38.214 alignment CR.
Agreement
The TP 2.8-1 in section 2.8.1 of R1- 2403519 is endorsed for inclusion in 38.214.
Agreement
The TP 2.9-1 in section 2.9.1 of R1- 2403519 is endorsed for inclusion in 38.214.
R1-2403520 Feature Lead summary #2 for Positioning for RedCap UEs Moderator (Ericsson)
From Thursday session
Agreement
The TP 2.3-1b in section 2.3.1 of R1- 2403520 is endorsed for inclusion in 38.214.
Agreement
The TP 2.5-1d in section 2.5.3 of R1- 2403520 is endorsed for inclusion in 38.214.
Final summary in R1-2403521.
R1-2403547 Summary #1 on Measurements and reporting for SL positioning Moderator (vivo)
From Wednesday session
Agreement
Support the scenario that the SL-PRS Rx UE reports measurements for multiple Rx ARP-IDs for the same resource or different resource(s) from the same Tx UE in a single measurement report.
Indicate this agreement in the reply LS to RAN2 LS on decisions on SLPP.
Agreement
Respond in the reply LS to RAN2 LS on decisions on SLPP that:
· From RAN1 perspective, for location calculations for UE-based SL positioning, it should be possible that the Rx UE can be provided the information about association between Tx ARP-ID and already transmitted SL PRS. It is unclear whether current signalling design from RAN2 can support this scenario.
R1-2403621 Draft reply LS on decisions on SLPP vivo
Decision: The draft LS in R1-2403621 is endorsed. Final LS is approved in R1-2403622.
Final summary in R1-2403548.
From AI 5
R1-2401940 Questions on RAN1 parameter list RAN2, CATT
RAN1 response necessary. Moderated by Ren (CATT).
R1-2403544 FL Summary for the reply LS on RAN2’s questions on RAN1 parameter list Moderator (CATT)
Agreement
RAN1’s response on Question 1 is as follows:
Question 1: Does the parameter nr-ReportedDL-PRS-measurementBasedOnSingleOrMultihopRx also apply to NR DL-AoD positioning?
RAN1’s Response: Yes, the parameter nr-ReportedDL-PRS-measurementBasedOnSingleOrMultihopRx is also applicable to NR DL-AoD positioning.
Agreement
RAN1’s response on Question 2 is as follows:
Question 2: Is there only one dl-PRS-ID or are there multiple dl-PRS-IDs associated with the aggregated main and additional measurement, respectively?
RAN1’s Response: In RAN1’s understanding, if nr-DL-PRS-ResourceSetID uniquely identifies the DL-PRS Resource Sets across all the multiple dl-PRS-IDs of the same TRP, then only one dl-PRS-ID is needed to be associated with the aggregated main measurement and additional measurements. Otherwise, multiple dl-PRS-IDs are associated with the aggregated main and additional measurement in the measurement report.
Agreement
RAN1’s response on Question 3 is as follows:
Question 3: If there are multiple dl-PRS-IDs associated with main and additional measurements, respectively, should the list of the dl-PRS-IDs in additional measurements be included in the list of dl-PRS-IDs in the main measurement?
RAN1’s Response: There is no need to provide dl-PRS-ID(s) in additional measurement reporting since both main measurement and additional measurement are derived from the same TRP.
R1-2403635 Draft reply LS on questions on RAN1 parameter list CATT
Decision: The draft LS in R1-2403635 is endorsed. Final LS is approved in R1-2403636.
--------------
R1-2401949 LS on positioning MAC agreements RAN2, Huawei
RAN1 response necessary. Moderated by Jinhuan (Huawei).
R1-2403534 FLS#1 on reply LS on positioning MAC agreements Moderator (Huawei)
Agreement
RAN1’s response on Question 1 is as follows:
Regarding the minimum time gap between the last symbol of SL-PRS and the start of the first symbol of PSFCH reception that is associated with the PSSCH transmission on SL-PRS shared resource pool, a new RRC parameter is NOT needed.
R1-2403535 Draft reply LS on positioning MAC agreements Moderator (Huawei)
Decision: The draft LS in R1-2403535 is endorsed. Final LS is approved in R1-2403536.
--------------
R1-2401956 LS on SRS BW aggregation impact on other channels/signals RAN4, Huawei
RAN1 response necessary. Moderated by Jinhuan (Huawei).
R1-2403537 FLS#1 on LS reply on SRS BW aggregation impact on other channels/signals Moderator (Huawei)
Agreement
Reply to RAN4:
RAN1 confirms RAN1 has defined the solution to handle the impact of SRS transmission for BW aggregation on other channels/signals.
The relevant agreements are as follows:
|
Agreement For positioning SRS aggregation transmission in RRC_INACTIVE state, reuse Rel-17 prioritization rule of SRS outside initial BWP, i.e. SRS is dropped in the symbol(s) of all aggregated carriers where collision occurs.
Agreement When an SRS resource configured within a CC without PUSCH/PUCCH is linked for aggregation with an SRS resource configured within an UL active BWP of a UL communication CC, a guard period is needed before and after the aggregated SRS transmissions. · Send an LS to RAN4 with the above information and a request to provide the retuning time values needed.
Agreement In RRC_CONNECTED state, for positioning SRS aggregation across CCs, if SRS in one of aggregated carriers is dropped in a symbol, stop SRS transmission in all aggregated carriers in the same symbol |
In addition, RAN1 also has defined a FG41-4-9 indicating which other bands in the band combination are affected due to the need of a guard period.
Action to RAN4:
RAN1 respectfully requests RAN4 to take above information into account in their future work.
R1-2403538 Draft reply LS on SRS BW aggregation impact on other channels/signals Moderator (Huawei)
Decision: The draft LS in R1-2403538 is endorsed with the deletion of the FG table and deletion of “as follows”. Final LS is approved in R1-2403539.
